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.
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. 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
