matplotlib-devel Mailing List for matplotlib

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

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.
> 
> Cheers,
> Mike

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. 
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.
Cheers,
Mike

Michael Droettboom wrote:
> Eric Firing wrote:
>> I also made memleak_gui.py more flexible with arguments. For example, 
>> here are tests with three backends, a generous number of loops, and 
>> suppression of intermediate output:
> 
> Those changes are really helpful. I just added code to display the 
> total number of objects in the Python interpreter (len(gc.get_objects()) 
> with each iteration as well, as that can be useful. (It doesn't rule 
> out memory leaks, but if it is increasing, that is definitely a problem.)
> 
> I also added a commandline option to print out any cycles involving 
> uncollectable objects, and added the necessary function to do so to 
> cbook.py.
> 
> Cheers,
> Mike
Mike,
Good, thank you.
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.)
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.
Eric

Eric Firing wrote:
> I also made memleak_gui.py more flexible with arguments. For example, 
> here are tests with three backends, a generous number of loops, and 
> suppression of intermediate output:
Those changes are really helpful. I just added code to display the 
total number of objects in the Python interpreter (len(gc.get_objects()) 
with each iteration as well, as that can be useful. (It doesn't rule 
out memory leaks, but if it is increasing, that is definitely a problem.)
I also added a commandline option to print out any cycles involving 
uncollectable objects, and added the necessary function to do so to 
cbook.py.
Cheers,
Mike