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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gustavo Gutierrez
Sent: Wednesday, October 29, 2008 9:19 AM
To: Christian Schulte
Cc: [EMAIL PROTECTED]
Subject: Re: [gecode-users] Reporting memory usage

 

 

On Tue, Oct 28, 2008 at 6:19 PM, Christian Schulte <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
https://www.gecode.org/mailman/listinfo/gecode-users

Reply via email to