[matplotlib-devel] Memory leak using savefig with MacOSX backend?
I'm looping over several files (about 1000) to produce a vector field
plot for each data file I have. Doing this with the MacOSX backend
appears to chew memory. My guess as to the source of the problem is
the 'savefig' function (or possibly the way the MacOSX backend handles
the saving of plots).
I opened Activity Monitor to watch the usage of memory increase. Below
is code that recreates the problem.
[start]
import matplotlib
matplotlib.use('macosx')
matplotlib.rc('font',**{'family':'serif','serif':['Computer Modern
Roman']})
matplotlib.rc('text', usetex=True)
from pylab import *
i = 0
x = []
y = []
v1 = []
v2 = []
while(True):
f = open("%dresults.dat"%i,"r")
for line in f:
x.append(float(line.split()[0]))
y.append(float(line.split()[1]))
v1.append(float(line.split()[2]))
v2.append(float(line.split()[3]))
f.close()
hold(False)
figure(1)
quiver(x, y, v1, v2, color='b', units='width', scale=1.0)
xlabel('$x$')
ylabel('$y$')
grid(True)
print i
savefig('graph-%05d.pdf'%i)
close(1)
x = []
y = []
v1 = []
v2 = []
i = i + 1
[end]
Regards,
--Damon
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leak using savefig with MacOSX backend?
I am also finding the continuing increase in memory usage, but this also occurs
with other backends (I tried tkagg and pdf) and also without the call to
savefig. One possibility is a circular reference in the quiver function that
prevents data from being cleaned up.
--Michiel
--- On Mon, 1/19/09, Damon McDougall wrote:
> From: Damon McDougall
> Subject: [matplotlib-devel] Memory leak using savefig with MacOSX backend?
> To: "matplotlib development list"
> Date: Monday, January 19, 2009, 6:09 AM
> I'm looping over several files (about 1000) to produce a
> vector field plot for each data file I have. Doing this with
> the MacOSX backend appears to chew memory. My guess as to
> the source of the problem is the 'savefig' function
> (or possibly the way the MacOSX backend handles the saving
> of plots).
>
> I opened Activity Monitor to watch the usage of memory
> increase. Below is code that recreates the problem.
>
> [start]
>
> import matplotlib
> matplotlib.use('macosx')
> matplotlib.rc('font',**{'family':'serif','serif':['Computer
> Modern Roman']})
> matplotlib.rc('text', usetex=True)
> from pylab import *
>
> i = 0
> x = []
> y = []
> v1 = []
> v2 = []
>
> while(True):
> f = open("%dresults.dat"%i,"r")
> for line in f:
> x.append(float(line.split()[0]))
> y.append(float(line.split()[1]))
> v1.append(float(line.split()[2]))
> v2.append(float(line.split()[3]))
> f.close()
> hold(False)
> figure(1)
> quiver(x, y, v1, v2, color='b',
> units='width', scale=1.0)
> xlabel('$x$')
> ylabel('$y$')
> grid(True)
> print i
> savefig('graph-%05d.pdf'%i)
> close(1)
> x = []
> y = []
> v1 = []
> v2 = []
> i = i + 1
>
>
> [end]
>
> Regards,
> --Damon
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leak using savefig with MacOSX backend?
On Mon, Jan 19, 2009 at 6:33 AM, Michiel de Hoon wrote: > I am also finding the continuing increase in memory usage, but this also > occurs with other backends (I tried tkagg and pdf) and also without the call > to savefig. One possibility is a circular reference in the quiver function > that prevents data from being cleaned up. I do not know how relevant this is to the problem at hand, but I have observed memory leaks in the Delaunay code in matplotlib 0.98.3. I hadn't had the chance to upgrade to 0.98.5.x yet, but judging from the release notes the issue was not fixed. Since the leak happens from inside Sage I need to find out what exactly causes those leaks before poking around and fixing them. > --Michiel > Cheers, Michael -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] MPL using Python2.6.1 on Windows
Greetings,
This weekend I decided to try and build mpl for windows using python
2.6.1. I was able to build numpy and mpl and I thought things were
great. However, when I tried to run a script with a show() function,
nothing would happen. Looking into this, I discovered that mpl didn't
recognize Tkinter during it's building process. I checked the
setupext.py code and found that python 2.6 wast excluded in the
windows section, even though Tkinter at least imports using python2.6.
I also noticed that there appears to be a hold over to a previous
version of mpl by including references to python 2.2, even though the
TCL/TK headers and libs for TCL/TK 8.3 aren't included in win32_static
version anymore. I decided to build TCL/TK 8.5 (which is what python
2.6 ships with) and dumped the appropriate libs in the lib directory
of win32_static and the header files into include/tcl85 directory. I
then changed references from python 2.2 to use python 2.6 (including
using TCL/TK 8.5 instead of 8.3), rebuilt mpl, and ran it. This time
the show window opens, however as the figure is being drawn an error
occurs and the figure window remains blank. Below is the traceback:
Exception in Tkinter callback
Traceback (most recent call last):
File "D:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "D:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 212, in resize
self.show()
File "D:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 216, in draw
tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
File "D:\Python26\lib\site-packages\matplotlib\backends\tkagg.py",
line 19, in blit
tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode,
id(bbox_array))
TclError
This is as far as I've been able to go (so far) in tracking down the
issue. I'll admit that I haven't looked much farther due to time
constraints, so if anyone else has suggestions as to where to go next,
I'm all ears. I'm not sure who the windows guru is for mpl, but if I
(we) can figure this problem out, I'll work with them in getting mpl
ready for 2.6 on windows.
Thanks,
-Patrick
--
Patrick Marsh
Graduate Research Assistant
School of Meteorology
University of Oklahoma
http://www.patricktmarsh.com
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots
> -Original Message- > From: Michael Droettboom [mailto:md...@stsci.edu] > Sent: 16 Jan 2009 1:31 PM > To: Andrew Hawryluk > Cc: matplotlib-devel@lists.sourceforge.net > Subject: Re: [matplotlib-devel] path simplification can decrease the > smoothness of data plots > > Michael Droettboom wrote: ... > I've attached a patch that will only include points from the original > data in the simplified path. I hesitate to commit it to SVN, as these > things are very hard to get right -- and just because it appears to > work better on this data doesn't mean it doesn't create a regression on > something else... ;) That said, it would be nice to confirm that this > solution works, because it has the added benefit of being a little > simpler computationally. Be sure to blitz your build directory when > testing the patch -- distutils won't pick it up as a dependency. > > I've attached two PDFs -- one with the original (current trunk) > behavior, and one with the new behavior. I plotted the unsimplified > plot in thick blue behind the simplified plot in green, so you can see > how much deviation there is between the original data and the > simplified line (you'll want to zoom way in with your PDF viewer to see > it.) > > I've also included a new version of your test script which detects > "new" > data values in the simplified path, and also seeds the random number > generator so that results are comparable. I also set the > solid_joinstyle to "round", as it makes the wiggliness less pronounced. > (There was another thread on this list recently about making that the > default setting). > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA Thanks for looking into this! The new plot is much improved, and the simplified calculations are a pleasant surprise. I was also testing the previous algorithm with solid_joinstyle set to "round" as it is the default in my matplotlibrc. I am probably not able to build your patch here, unless building matplotlib from source on Windows is easier than I anticipate. May I send you some data off the list for you to test? Regards, Andrew NOVA Chemicals Research & Technology Centre Calgary, Canada -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
