[gecode-users] Reporting memory usage

[Christian Schulte]

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> 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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ps.uni-sb.de/pipermail/users/attachments/20081030/caacf7cc/attachment.htm>