On Wed, Feb 29, 2012 at 9:55 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > Python uses a garbage collector to reclaim memory. Objects don't die just > because they fall out of scope, they will be around until the next GC cycle.
Minor note: At least when using Cython, sometimes objects will be freed when they fall out of scope if they are not part of a circular reference cycle. It is useful to look at python-2.7.2.p1/src/Include/object.h to see what Py_DECREF actually does. > > You can force the garbage collector with > > import gc > gc.collect() > > but that is a rather expensive operation so you don't want to do call it all > the time. > > > > > On Wednesday, February 29, 2012 6:30:47 AM UTC-8, Nathann Cohen wrote: >> >> Hello everybody !!! >> >> There has been a bug report [1, 2] on "ask Sage" about a memory leak with >> CPLEX. I checked, and it is True. But I do not think I know how to patch >> that. >> >> Here is the thing : the dominating_set function (among many others) uses >> Linear Programming, and so creates a LP object when it is called. The LP >> object *should* disappear by itself when the method returns its result, but >> I observed a STRANGE behaviour... >> >> sage: graphs.PetersenGraph().dominating_set() >> IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic >> Initiative" is accessing CPLEX 12 with option(s): "e m b q ". >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: # At this moment I just *do nothing* for a few seconds..... >> sage: graphs.PetersenGraph().dominating_set() >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: graphs.PetersenGraph().dominating_set() >> [1, 4, 5] >> sage: exit >> Exiting Sage (CPU time 0m0.27s, Wall time 0m13.47s). >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> __dealloc__ called ! >> >> Well. With this kind of behaviour, no wonder a loops ends up eating a lot >> of memory, but then I do not know what to do anymore... Should I call "del" >> explicitely at the end of each function ? Thank you for your help O_o;;; >> >> Nathann >> >> [1] http://ask.sagemath.org/question/1170/memory-blowup-with-milp >> [2] http://ask.sagemath.org/question/1191/memory-blowup-2 > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
