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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-users
