Yes, I saw that, tried putting in explicit gc.collect()
> calls, but it didn't help. I concluded the problem was
> different. I also looked at the draw function in
> backend_gtk.py. What I don't understand is how and when the
> no-longer-used gtk objects (pixmap, etc) really can and
> should be de-allocated. Evidently they persist when the
> python reference to them goes out of scope.
> Thanks for your changes.
Hi Eric,
You can test the new release which includes both Steve's changes and a
number of fixes on my end. I'll attach the script below that I used
to profile the leak, a modified version of your script. By my
numbers, the average memory consumed per loop is down from 145.9 using
0.54.1 to 12.3 using 0.54.2. Not perfect, but more than 10x better.
I have definitely identified a leak in freetype (as mentioned above,
which is fixed in freetype CVS) and there appears to be a leak in
libpng but I have tracked down precisely where. Neither of these are
terribly large. I strongly suspect that some of the remaining leak is
my doing, so I'll continue to try and sniff these out. The python
code uses a lot of circular references (figures contain axes and text
which in turn contain a reference to the figure that contains them and
so on) which makes the task a little harder.
Let me know how it goes.
JDH
import os, sys, time
import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *
def report_memory(i):
pid = os.getpid()
a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
print i, ' ', a2[1],
return int(a2[1].split()[0])
def updatefig(i):
ind = arange(100)
xx = rand(len(ind), 1)
figure(1)
plot(ind, xx[:,0])
savefig('dd_ef%d.png' % i, dpi = 75)
close(1)
return report_memory(i)
N = 100
for i in range(N):
val = updatefig(i)
if i==1: start = val
end = val
print 'Average memory consumed per loop: %1.4f\n' % ((end-start)/float(N))