As I have no idea what's inside your model I can't say a thing. Do you store BExpr somewhere? What other datastructures do you use? How many and which propagators?
Yes, Statistics.getMemory() refers to the C++ memory. Christian -- Christian Schulte, www.ict.kth.se/~cschulte/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Malcolm Ryan Sent: Monday, April 07, 2008 6:53 AM To: gecode list Subject: Re: [gecode-users] Controlling memory use 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 _______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users _______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
