Michael Droettboom wrote: > Eric Firing wrote: >> So, this test is still showing problems, with similar memory >> consumption in these three backends. > Not necessarily. By default, Python allocates large pools from the > operating system and then manages those pools itself (though its > PyMalloc call). Prior to Python 2.5, those pools were never freed. > With Python 2.5, empty pools, when they occur, are freed back to the > OS. Due to fragmentation issues, even if there is enough free space in > those pools for new objects, new pools may need to be created anyway, > since Python objects can't be moved once they are created. So seeing > modest increases in memory usage during a long-running Python > application is typical, and not something that can be avoided > wiinaccurate at finding memory leaksthout micro-optimizing for pool > performance (something that may be very difficult). If memory usage is > truly increasing in an unbounded way, then, yes, there may be problems, > but it should eventually stabilize (though in a test such as memleak_gui > that may take many iterations). It's more interesting to see the curve > of memory usage over time than the average over a number of iterations.
I agree. I just ran 2000 iterations with GtkAgg, plotted every 10th point, and the increase is linear (apart from a little bumpiness) over the entire range (not just the last 1000 iterations reported below): Backend GTKAgg, toolbar toolbar2 Averaging over loops 1000 to 2000 Memory went from 31248k to 35040k Average memory consumed per loop: 3.7920k bytes Maybe this is just the behavior of pymalloc in 2.5? > For further reading, see: > http://evanjones.ca/python-memory.html > README.valgrind in the Python source > http://mail.python.org/pipermail/python-dev/2006-March/061991.html > > Because of this, using the total memory allocated by the Python process > to track memory leaks is pretty blunt tool. More important metrics are > the total number of GC objects (gc.get_objects()), GC garbage > (gc.garbage), and using a tool like Valgrind or Purify to find > mismatched malloc/frees. Another useful tool (but I didn't resort to > yet with matplotlib testing) is to build Python with COUNT_ALLOCS, which > then gives access to the total number of mallocs and frees in the Python > interpreter at runtime. > > IMO, the only reasonable way to use the total memory usage of Python to > debug memory leaks is if you build Python without pool allocation > (--without-pymalloc). That was how I was debugging memory leaks last > week (in conjunction with valgrind, and the gc module), and with that > configuration, I was only seeing memory leakage with Pygtk 2.4, and a > very small amount with Tk. Are your numbers from a default build? If > so, I'll rebuild my Python and check my numbers against yours. If they > match, I suspect there's little we can do. I used stock Python 2.5 from ubuntu Feisty. I should compile a version as you suggest, but I haven't done it yet. Eric > > Cheers, > Mike > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
