From: Darren D. <dd...@co...> - 2007-07-03 20:43:59
|
On Tuesday 03 July 2007 04:33:46 pm Eric Firing wrote: > Michael Droettboom wrote: > > Eric Firing wrote: > >> I just committed a change to the output formatting of memleak_gui so > >> that if you redirect it to a file, that file can be loaded with > >> pylab.load() in case you want to plot the columns. (At least this is > >> true if you don't use the -c option.) > > > > Great. Sorry for stomping on that ;) > > > >> Yesterday, before your commits, I compared memleak_gui with stock > >> Python 2.4 versus stock 2.5 (both from ubuntu feisty) and found very > >> little difference in the OS memory numbers. > > > > Are they still increasing linearly? I'm still seeing some mystery leaks > > with Gtk, Qt4 and (much smaller) on Tk. Qt and Wx seem fine here. > > Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of > results: tkagg is best, with only slow memory growth and a constant > number of python objects; qtagg grows by 2.2k per loop, with no increase > in python object count; wx (which is built on gtk) consumes 3.5k per > loop, with an increasing object count; gtk consumes 1.8k per loop with > an increasing object count. > > All runs are on stock ubuntu feisty python 2.5. > > Eric > > > Unfortunately Qt4 crashes valgrind, so it's not of much use. > > I'm curious whether your results match that. I'm not terribly surprised > > that 2.4 isn't different from 2.5, since the case in which entire memory > > pools are freed in 2.5 is probably hard to trigger. I am swamped at work, and have not been able to follow this thread closely. But I just updated from svn and ran memleak_gui.py with qt4: # columns are: iteration, OS memory (k), number of python objects # 0 37364 53792 10 37441 53792 20 37441 53792 30 37525 53792 40 37483 53792 50 37511 53792 60 37539 53792 70 37568 53792 80 37596 53792 90 37624 53792 100 37653 53792 # columns above are: iteration, OS memory (k), number of python objects # # uncollectable list: [] # # Backend Qt4Agg, toolbar toolbar2 # Averaging over loops 30 to 100 # Memory went from 37525k to 37653k # Average memory consumed per loop: 1.8286k bytes Darren |