[gecode-users] Reporting memory usage

Filip Konvička filip.konvicka at logis.cz
Thu Oct 30 12:32:38 CET 2008


Hi Christian,

actually this has been on my todo list for some time: I tend to use stl 
containers here and there in my branchings, so the nice thing here would 
be providing some allocators that allocate from space memory, which 
would enable us to use things like std::set, std::unordered_set etc. 
without hassle. Another nice thing is that I would no longer need to 
enforce calling destructors of members manually in "dispose()". I'll 
take a look at the space memory API to see whether it's possible.

Cheers,
Filip

> Hi,
> 
>  
> 
> The only reason to allocate globally and not from a space is if the 
> allocated entities are shared among several spaces. That's the case for 
> complete set variables as they use BDDs that might indeed be shared 
> across spaces.
> 
>  
> 
> Unless you share across spaces you should always allocate from a space, 
> it's much faster (an deallocation is automatic as soon as the space gets 
> deleted)! But in any case, make sure that you do not leak memory
> 
>  
> 
> Cheers
> 
> Christian
> 
>  
> 
> --
> 
> Christian Schulte, www.ict.kth.se/~cschulte/
> 
>  
> 
> *From:* users-bounces at gecode.org 
> [mailto:users-bounces at gecode.org] *On 
> Behalf Of *Gustavo Gutierrez
> *Sent:* Wednesday, October 29, 2008 9:19 AM
> *To:* Christian Schulte
> *Cc:* gecode at gecode.org
> *Subject:* Re: [gecode-users] Reporting memory usage
> 
>  
> 
>  
> 
> On Tue, Oct 28, 2008 at 6:19 PM, Christian Schulte 
> <cschulte at kth.se 
> <mailto:cschulte at kth.se>> wrote:
> 
> Hi,
> 
>  
> 
> Damn that's missing in Gecode. A space takes into account what external 
> memory is allocated by propagators and branchings but not by variables.
> 
>  
> 
> It will also not be that straightforward (I would have to think a 
> little) as a space does not maintain a list of all variables (in 
> contrast to propagators and branchings). 
> 
>      
> 
>     Is it very important? If yes, we could try to come up with something
>     and add it for 3.0.
> 
> It would be nice and useful to have it but of course we can use some 
> workaround:  what we can do for now is to use some bash scripting to 
> measure the memory allocated by an specific process, unfortunately this 
> is not so standard from one operating system to another.
> 
>  
> 
>  
> 
>  
> 
>     What do you do right now? Do you use the same memory management
>     support for variables that is also used by the complete set variables?
> 
> If i remember correctly, cpltset variables use an external library in 
> the buddy folder and use a disposer to free the memory allocated by 
> additional data structures. We are doing that right now. We are trying 
> to use boost libraries for our implementation and fortunately those 
> libraries provide a way to parametrize the allocator. The other 
> possibility will be to use an allocator that allocates memory from the 
> gecode heap and *never* deallocate it (this is because gecode memory 
> manager takes care of that (am i right?). Can you recommend or comment 
> on the advantages of one approach over the other?
> 
>  
> 
> Regards,
> 
> Gustavo
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users





More information about the gecode-users mailing list