Ok. I think I've found a leak in the way the spines' paths were being updated.
https://github.com/matplotlib/matplotlib/pull/89 Can you apply the patch there and let me know how it improves things for you? Cheers, Mike On 04/21/2011 08:35 AM, Caleb Constantine wrote: > On Wed, Apr 20, 2011 at 1:04 PM, Michael Droettboom<md...@stsci.edu> wrote: > >> On 04/20/2011 11:27 AM, Caleb Constantine wrote: >> >>> On Wed, Apr 20, 2011 at 9:29 AM, Michael Droettboom<md...@stsci.edu> >>> wrote: >>> >>>> On 04/20/2011 07:48 AM, Caleb Constantine wrote: >>>> >>>>> On Tue, Apr 19, 2011 at 2:25 PM, Michael Droettboom<md...@stsci.edu> >>>>> wrote: >>>>> >>>>>> Ok. I have a RHEL5 Linux box with Python 2.7.1. >>>>>> >>>>>> With Numpy 1.4.1 and 1.5.1 I don't see any leaks. With Numpy git HEAD, >>>>>> I did see a leak -- I submitted a pull request to Numpy here: >>>>>> >>>>>> https://github.com/numpy/numpy/pull/76 >>>>>> >>>>>> I get the same results (no leaks) running your wx, tk and agg scripts >>>>>> (with the Windows-specific stuff removed). >>>>>> >>>>>> FWIW, I have wxPython 2.8.11.0 and Tkinter rev 81008. >>>>>> >>>>>> So the variables are the platform and the version of Python. Perhaps >>>>>> it's one of those two things? >>>>>> >>>>>> Mike >>>>>> >>>>> Consider the following: >>>>> >>>>> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, >>>>> Windows XP SP3 >>>>> >>>>> - 1 hour >>>>> - Plotted 3601 times, about 1Hz >>>>> - Memory usage increased by about 1.16MB (41.39 - 40.23), or >>>>> about 0.33K per redraw >>>>> >>>>> It seems the same memory leak exists. Given you don't have this issue >>>>> on Linux with the same Python configuration, I can only assume it is >>>>> related to some Windows specific code somewhere. I'll run for a longer >>>>> period of time just in case, but I don't expect the results to be >>>>> different. >>>>> >>>> One way to rule out Windows-specific code may be to run with the Agg >>>> backend only (without wx). Have you plotted the memory growth? This >>>> amount of memory growth is well within the pool allocation sizes that >>>> Python routinely uses. Does the value of len(gc.get_objects()) grow >>>> over time? >>>> >>>> >>> New results follows. >>> >>> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP >>> SP3 >>> >>> agg >>> - 3601 redraws (1 hour), about 1Hz >>> - Memory usage: 28.79 - 27.57 = 1.22 MB >>> - len(gc.get_objects()): 23424 at beginning and end >>> - Plot of memory growth: roughly linear, increasing with slope of 0.26KB >>> >>> tkagg >>> - 3601 redraws (1 hour), about 1Hz >>> - Memory usage: 33.22 - 33.32 = -0.1 MB >>> - len(gc.get_objects()): 24182 at beginning and end >>> - Plot of memory growth: very irregular (up and down), but a line fit >>> has a slope of about 0.025KB (I could run longer and see if slope >>> approaches 0) >>> >>> wxagg >>> - 3601 redraws (1 hour), about 1Hz >>> - Memory usage: 43.28 - 41.80 = 1.5 MB >>> - len(gc.get_objects()): 41473 at beginning and end >>> - Plot of memory growth: roughly linear, increasing with slope of 0.32KB >>> >> Thanks. These are very useful results. >> >> The fact that gc.get_objects() remains constant suggests to me that this >> is not a simple case of holding on to a Python reference longer than we >> intend to. Instead, this is either a C-side reference counting bug, or >> a genuine C malloc-and-never-free bug. Puzzlingly, valgrind usually >> does a very good job of finding such bugs, but is turning up nothing for >> me. Will have to scratch my head a little bit longer and see if I can >> come up with a proper experiment that will help me get to the bottom of >> this. >> >> > For completeness, I ran more tests over a 10 hour period at an > increased redraw rate. Details follows. Note tkagg memory usage is > flat, agg and wxagg are not. > > matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP SP3 > > agg > - 52214 redraws > - Memory usage: 27.55 - 43.46 = 15.22 MB > - len(gc.get_objects()): 23424 at beginning and end > - Plot of memory growth: linear, increasing with slope of 0.31KB > > tkagg > - 71379 redraws > - Memory usage: 30.47 - 30.25 = 0.22 MB > - len(gc.get_objects()): 24171 at beginning, 24182 at end, but mostly > constant at 24182 > - Plot of memory growth: very irregular (up and down), but a line fit > has a slope of about 0.0002KB. > > wxagg > - 72001 redraws > - Memory usage: 62.08 - 40.10 = 21.98 MB > - len(gc.get_objects()): 41473 at beginning and end > - Plot of memory growth: linear, increasing with slope of 0.31KB > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
