On Thu, Feb 3, 2011 at 6:37 PM, Christoph Gohlke <cgoh...@uci.edu> wrote:
>
>
> On 2/3/2011 3:13 PM, Eric Firing wrote:
> > On 02/03/2011 01:02 PM, Christoph Gohlke wrote:
> >>
> >>
> >> 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.
> >
> > It is, but if there are circular reference chains (cycles--and mpl is
> > full of them) then the garbage collector has to identify them and remove
> > them. If it encounters a __del__ it stops and leaves that cycle alone.
> >
>
> My understanding is that if there is a circular reference then the
> refcount will not be zero anyway. In this case _AxesImageBase instances
> and their image caches will never be deleted by the gc (__del__ method
> present or not) unless the circle is broken. When the interpreter quits
> things are deleted by other means. I don't know matplotlib code good
> enough to fix this and will instead work on reducing the memory overhead
> needed to plot an image. In the meantime it could help to explicitly
> delete the image cache when a plot closes or to avoid caching altogether.
>
> Christoph
>
>
Just to clarify the circular reference paradox. The garbage collector will
pick it up because it is using weak refs instead of regular references. So,
when a circular reference occurs, but is not hard ref-ed to anything, then
it is "detached" and the gc picks it up. I am not very familiar on this
concept in particular, but I do remember it being explained this way.
Anyone who is more knowledgeable about this, I would welcome further comment
or corrections to what I remember.
Also, not to sound too annoying, but has anyone considered the idea of using
compressed arrays for holding those rgba values?
Ben Root
------------------------------------------------------------------------------
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
