On 2/3/2011 2:44 PM, Eric Firing wrote: > On 02/03/2011 12:28 PM, Christoph Gohlke wrote: >> >> >> On 2/3/2011 2:15 PM, Eric Firing wrote: >>> On 02/03/2011 11:30 AM, Robert Abiad wrote: >>>> On 2/3/2011 10:06 AM, Eric Firing wrote: >>>>> On 02/02/2011 10:17 PM, Eric Firing wrote: >>>>>> On 02/02/2011 08:38 PM, Robert Abiad wrote: >>>>>>> >>>>>> [...] >>>>>>> I'll put it in as an enhancement, but I'm still unsure if there is a >>>>>>> bug in >>>>>>> there as well. Is there something I should be doing to clear memory >>>>>>> after the >>>>>>> first figure is closed other than close()? I don't understand why >>>>>>> memory usage >>>>>>> grows each time I replot, but I'm pretty sure it isn't desireable >>>>>>> behavior. As >>>>>>> I mentioned, this effect is worse with plot. >>>>>>> >>>>>>> So is this a bug or improper usage? >>>>>> >>>>>> I'm not quite sure, but I don't think there is a specifically >>>>>> matplotlib >>>>>> memory leak bug at work here. Are you using ipython, and if so, have >>>>>> you >>>>>> turned off the caching? In its default mode, ipython keeps lots of >>>>>> references, thereby keeping memory in use. Also, memory management and >>>>>> reporting can be a bit tricky and misleading. >>>>>> >>>>>> Nevertheless, the attached script may be illustrating the problem. Try >>>>>> running it from the command line as-is (maybe shorten the loop--it >>>>>> doesn't take 100 iterations to show the pattern) and then commenting >>>>>> out >>>>>> the line as indicated in the comment. It seems that if anything is done >>>>>> that adds ever so slightly to memory use while the figure is displayed, >>>>>> then when the figure is closed, its memory is not reused. I'm puzzled. >>>>> >>>>> I wasn't thinking straight--there is no mystery and no memory leak. >>>>> Ignore my example script referred to above. It was saving rows of the z >>>>> array, not single elements as I had intended, so of course memory use >>>>> was growing substantially. >>>>> >>>>> Eric >>>>> >>>> >>>> You may not see a memory leak, but I still can't get my memory back >>>> without killing python. I >>>> turned off the ipython caching and even ran without iPython on both >>>> Windows and Ubuntu, but when I >>>> use imshow(), followed by close('all') and another imshow(), I run out >>>> of memory. I can see from >>>> the OS that the memory does not come back after close() and that it >>>> grows after the second imshow(). >>>> >>>> Any other ideas? Looks like a bug to me otherwise. >>> >>> Except that I tried the same things and did not get quite the same >>> result. Let's track this down. Please try the attached script, and see >>> if the memory usage grows substantially, or just oscillates a bit. >>> >>> Eric >>> >> >> >> One thing I noticed is that if I add a "def __del__(self): print 'del'" >> to image._AxesImageBase, it never gets called. _AxesImageBase keeps >> float64 and uint8 rgba images in a cache, which is never freed. > > Adding a __del__ method defeats (or blocks) the garbage collection. >
Sorry, never heard of that. I thought __del__() is called when the reference count reaches 0. Christoph > Since self._imcache is an instance attribute, when the instance is no > longer referenced, it should get garbage-collected, provided there is no > __del__ method. > > Eric > >> >> Christoph >> >> >> ------------------------------------------------------------------------------ >> The modern datacenter depends on network connectivity to access resources >> and provide services. The best practices for maximizing a physical server's >> connectivity to a physical network are well understood - see how these >> rules translate into the virtual world? >> http://p.sf.net/sfu/oracle-sfdevnlfb >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users