[gecode-users] Controlling memory use

[Malcolm Ryan]

On 01/04/2008, at 5:57 PM, Christian Schulte wrote:
> Yes, as said only copy the variables you consider important for your
> solution, the other variables are managed automatically and will  
> kept only
> if needed.

Can I do the reverse and only add variables to the space as they  
become relevant?

> If the tree is deep and there is little failure, be aggressive with  
> the
> copying recomputation (called c_d): try fifty or more for you  
> example. This
> controls how often a copy is created (so every c_d search steps). To  
> protect
> from pathological behavior you can set the adaptive recomputation  
> distance
> (called a_d): try ten or so. This controls behavior when failure  
> occurs:
> when a space fails it will create intermediate copies to speed up  
> further
> failures (it is likely that when search fails once it will fail  
> often, as
> most likely not the last branch is wrong but some branch higher up  
> in the
> tree).

I've tried this and managed to bring the sizes down a bit. After  
making a couple of changes to prune unnecessary variables, I now have  
the following results for a 'small' problem with 1273 variables:

Clones: 43
Commits: 326
Fails: 1
Propagates: 658217

C_d    A_d    Memory (Mb)
8      2      210.6
50     10      45.1
100    10      30.1
200    10      21.9

This seems to improve things quite a bit, but I'm still somewhat  
disturbed by the size. I suspect that a lot of it may be accounted for  
by a large number of BExprs, which I believe create 'implicit'  
variables. Is that correct?

> For your particular example, I would really suspect some other  
> memory leak
> in Gecode/J: not only has your problem no search but it also has  
> almost no
> propagation.

I agree that the crash I experienced was probably due to a memory  
leak, but the memory figures I quote above are those returned by  
Statistics.getMemory()? Am I right in thinking that they represent  
just the usage of the C++ engine?

With this memory usage being so large, there is no way I would be able  
to solve a 'large' instance of my problem. Do you have any guidelines  
for most efficient memory use?

Malcolm