Menu
▾
▴
matplotlib-users
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-12 21:07:03
|
Dear all, I'm not sure if this is by design or a problem: In a pylab session, if I repeatedly call imshow with the same image, memory increases each time. This does not happen if i go the 'Artists' way (fig = .., ax = fig.add---, im = ax.imshow) Is there a way to avoid memory consumption like this in the pylab style? Even a clf() does not release the memory. My config is the latest Enthought distribution in 32-bit mode for MacOS. BR, Michael |
|
From: John H. <jd...@gm...> - 2010-07-12 21:17:27
|
On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye <kmi...@gm...> wrote: > Dear all, > > I'm not sure if this is by design or a problem: > > In a pylab session, if I repeatedly call imshow with the same image, > memory increases each time. > This does not happen if i go the 'Artists' way (fig = .., ax = > fig.add---, im = ax.imshow) > Is there a way to avoid memory consumption like this in the pylab style? > Even a clf() does not release the memory. > My config is the latest Enthought distribution in 32-bit mode for MacOS. > Can you post a complete free-standing script that we can run which exposes the problem? Also please report your version numbers -- we could look them up from enthought perhaps but you can help us :-) http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-12 22:07:00
|
On 2010-07-12 23:17:19 +0200, John Hunter said: > On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye > <kmi...@gm...> wrote: >> Dear all, >> >> I'm not sure if this is by design or a problem: >> >> In a pylab session, if I repeatedly call imshow with the same image, >> memory increases each time. >> This does not happen if i go the 'Artists' way (fig = .., ax = >> fig.add---, im = ax.imshow) >> Is there a way to avoid memory consumption like this in the pylab style? >> Even a clf() does not release the memory. >> My config is the latest Enthought distribution in 32-bit mode for MacOS. >> > > > Can you post a complete free-standing script that we can run which > exposes the problem? Also please report your version numbers -- we > could look them up from enthought perhaps but you can help us :-) Of course, sorry. But because I don't know how to read out Python's memory consumption from within python, these lines should be run successively in Ipython, so that one can see, how the 'Real Mem' system indicator grows each time. l = [28.1] arr = ones((1500,1500,3)) l.append(79.7) imshow(arr) l.append(172.0) imshow(arr) l.append(249.0)) l.append(249.0) imshow(arr) l.append(326.3)) l.append(326.3) imshow(arr) l.append(404.4) imshow(arr) l.append(482.4) This was run in an ipython session started with the -pylab flag. The numbers in the l array are the MBs I read of Mac's Activity Monitor for the Python task. Here is the resulting plot: http://dl.dropbox.com/u/139035/mem_growth.png Here's my system info: Darwin paradigm.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 In [25]: print matplotlib.__version__ -------> print(matplotlib.__version__) 0.99.3 Enthought Python Distribution -- http://code.enthought.com Python 2.6.5 |EPD 6.2-2 (32-bit)| (r265:79063, May 28 2010, 15:13:03) my matplotlibrc (some adaptations): http://dl.dropbox.com/u/139035/matplotlibrc Hope this is all you need? BR, Michael > > http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first |
|
From: John H. <jd...@gm...> - 2010-07-13 23:46:56
|
On Mon, Jul 12, 2010 at 5:06 PM, K.-Michael Aye <kmi...@gm...> wrote: > On 2010-07-12 23:17:19 +0200, John Hunter said: > >> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye >> <kmi...@gm...> wrote: >>> Dear all, >>> >>> I'm not sure if this is by design or a problem: It's by design and is not a leak. matplotlib supports multiple images on the same axes, and can composite multiple images that overlap the same space using transparency, so each call to imshow is adding additional data to the axes. You can inspect the ax.images list to see the list of images is growing. If you have an Image object and want to remove it from the Axes, call im.remove() or you can manipulate the list of ax.images directly, eg del ax.images[0] or if you have a single image and want to update the data in it, you can do im = ax.imshow(something) im.set_array(newdata) to update the array in the existing image. JDH |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-14 15:19:19
|
On 2010-07-14 01:46:49 +0200, John Hunter said:
> On Mon, Jul 12, 2010 at 5:06 PM, K.-Michael Aye
> <kmi...@gm...> wrote:
>> On 2010-07-12 23:17:19 +0200, John Hunter said:
>>
>>> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye
>>> <kmi...@gm...> wrote:
>>>> Dear all,
>>>>
>>>> I'm not sure if this is by design or a problem:
>
> It's by design and is not a leak. matplotlib supports multiple images
> on the same axes, and can composite multiple images that overlap the
> same space using transparency, so each call to imshow is adding
> additional data to the axes.
Understood, and of course quite useful. But see below.
> You can inspect the ax.images list to
> see the list of images is growing.
>
> If you have an Image object and want to remove it from the Axes, call
>
> im.remove()
This worked.
> or you can manipulate the list of ax.images directly, eg
>
> del ax.images[0]
I tried this and got this error message:
In [10]: del ax.images.remove[0]
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/Users/aye/Documents/workspace/pyrise_saver_clone/src/<ipython console>
in <module>()
TypeError: 'builtin_function_or_method' object does not support item deletion
Here my history of that session:
1 : from fan_finder import get_data
2 : data = get_data(2)
3 : fig = figure()
4 : ax = fig.add_subplot(111)
5 : im = imshow(data)
6 : ax.images
7 : im = imshow(data)
8 : ax.images
9 : ax.images.remove[0]
10: del ax.images.remove[0]
11: hist%
12: _ip.magic("hist ")
data is a np.array
I found another funny thing:
Even so i set hold(False), and the ax.images array does not increase,
the memory consumption increases.
I used these commands:
3 : fig = figure()
4 : ax = fig.add_subplot(111)
5 : imshow(data)
6 : ax.images
7 : hold(False)
8 : imshow(data)
9 : ax.images
At step 6 I had 1 image in the ax.images array, at step 9 still only 1,
but RealMem went up the approx same amount between 7 and 8 then it did
between 4 and 5.
>
> or if you have a single image and want to update the data in it, you can do
>
> im = ax.imshow(something)
> im.set_array(newdata)
I am using this way in a GUI I programmed and works very well there.
BR,
Michael
>
> to update the array in the existing image.
>
> JDH
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
|
|
From: John H. <jd...@gm...> - 2010-07-14 15:46:37
|
On Wed, Jul 14, 2010 at 10:18 AM, K.-Michael Aye <kmi...@gm...> wrote: > On 2010-07-14 01:46:49 +0200, John Hunter said: > >> On Mon, Jul 12, 2010 at 5:06 PM, K.-Michael Aye >> <kmi...@gm...> wrote: >>> On 2010-07-12 23:17:19 +0200, John Hunter said: >>> >>>> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye >>>> <kmi...@gm...> wrote: >>>>> Dear all, >>>>> >>>>> I'm not sure if this is by design or a problem: >> >> It's by design and is not a leak. matplotlib supports multiple images >> on the same axes, and can composite multiple images that overlap the >> same space using transparency, so each call to imshow is adding >> additional data to the axes. > > Understood, and of course quite useful. But see below. > >> You can inspect the ax.images list to >> see the list of images is growing. >> >> If you have an Image object and want to remove it from the Axes, call >> >> im.remove() > > > This worked. > >> or you can manipulate the list of ax.images directly, eg >> >> del ax.images[0] > > I tried this and got this error message: > > In [10]: del ax.images.remove[0] > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > > /Users/aye/Documents/workspace/pyrise_saver_clone/src/<ipython console> > in <module>() > > TypeError: 'builtin_function_or_method' object does not support item deletion > > Here my history of that session: > > 1 : from fan_finder import get_data > 2 : data = get_data(2) > 3 : fig = figure() > 4 : ax = fig.add_subplot(111) > 5 : im = imshow(data) > 6 : ax.images > 7 : im = imshow(data) > 8 : ax.images > 9 : ax.images.remove[0] > 10: del ax.images.remove[0] Both of these lines are wrong. You either need to do ax.images.remove(0) # note the parens, not square brackets or del ax.images[0] Also, you are mixing API calls, eg ax = fig.add_subplot(111) with pyplot call, eg im = imshow(data) While this isn't a bug in this case, it is not good form. The pyplot calls manage stateful information like current image and current axes, and you are safer using all pyplot or all api. So for pure pyplot: subplot(111) imshow(data) or pure API: ax = fig.add_subplot(111) ax.imshow(data) > Even so i set hold(False), and the ax.images array does not increase, > the memory consumption increases. > > I used these commands: > > 3 : fig = figure() > 4 : ax = fig.add_subplot(111) > 5 : imshow(data) > 6 : ax.images > 7 : hold(False) > 8 : imshow(data) > 9 : ax.images > > At step 6 I had 1 image in the ax.images array, at step 9 still only 1, > but RealMem went up the approx same amount between 7 and 8 then it did > between 4 and 5. I don't see this -- try using gc.collect() if you think you see a leak and use cbook.report_memory to get a measure of consumed memory. If you still think you have a leak, try and build a complete free-standing script that replicates it. In [220]: import matplotlib.cbook as cbook In [221]: cbook.report_memory Out[221]: <function report_memory at 0x87fd5a4> In [222]: cbook.report_memory() Out[222]: 81733 In [223]: hold(False) In [224]: ax = gca() In [225]: len(ax.images) Out[225]: 1 In [226]: imshow(data) Out[226]: <matplotlib.image.AxesImage object at 0xc7455ec> In [227]: len(ax.images) Out[227]: 1 In [228]: cbook.report_memory() Out[228]: 81733 In [229]: imshow(data) Out[229]: <matplotlib.image.AxesImage object at 0xd4752ac> In [230]: len(ax.images) Out[230]: 1 In [231]: imshow(data) Out[231]: <matplotlib.image.AxesImage object at 0xe4ee72c> In [232]: len(ax.images) Out[232]: 1 In [233]: cbook.report_memory() Out[233]: 81733 JDH |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-14 16:39:06
|
>> 6 : ax.images
>> 7 : im = imshow(data)
>> 8 : ax.images
>> 9 : ax.images.remove[0]
>> 10: del ax.images.remove[0]
>
> Both of these lines are wrong. You either need to do
>
> ax.images.remove(0) # note the parens, not square brackets
>
> or
>
> del ax.images[0]
*doh*, of course, me stupid. Sorry, it's very very hot here. :)
>
> Also, you are mixing API calls, eg
>
> ax = fig.add_subplot(111)
>
> with pyplot call, eg
>
> im = imshow(data)
>
> While this isn't a bug in this case, it is not good form. The pyplot
> calls manage stateful information like current image and current axes,
> and you are safer using all pyplot or all api. So for pure pyplot:
>
> subplot(111)
> imshow(data)
>
> or pure API:
>
> ax = fig.add_subplot(111)
> ax.imshow(data)
Yeah, sorry, i thought it wouldn't matter, as i did not need an image
object for this demo.
>
>
>> Even so i set hold(False), and the ax.images array does not increase,
>> the memory consumption increases.
>>
>> I used these commands:
>>
>> 3 : fig = figure()
>> 4 : ax = fig.add_subplot(111)
>> 5 : imshow(data)
>> 6 : ax.images
>> 7 : hold(False)
>> 8 : imshow(data)
>> 9 : ax.images
>>
>> At step 6 I had 1 image in the ax.images array, at step 9 still only 1,
>> but RealMem went up the approx same amount between 7 and 8 then it did
>> between 4 and 5.
>
>
> I don't see this -- try using gc.collect() if you think you see a leak
> and use cbook.report_memory to get a measure of consumed memory. If
> you still think you have a leak, try and build a complete
> free-standing script that replicates it.
I only can reproduce it inside a pylab session, as you see here:
IPython 0.10 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
Welcome to pylab, a matplotlib-based Python environment.
For more information, type 'help(pylab)'.
In [1]: import gc
In [2]: gc.collect?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
String Form: <built-in function collect>
Namespace: Interactive
Docstring:
collect([generation]) -> n
With no arguments, run a full collection. The optional argument
may be an integer specifying which generation to collect. A ValueError
is raised if the generation number is invalid.
The number of unreachable objects is returned.
In [3]: import matplotlib.cbook as cbook
In [4]: data = ones((1500,1500,3))
In [5]: imshow(data)
Out[5]: <matplotlib.image.AxesImage object at 0x1c57610>
In [6]: ax =gca()
In [7]: cbook.report_memory()
Out[7]: 175384
In [8]: hold(False)
In [9]: len(ax.images)
Out[9]: 1
In [10]: imshow(data)
Out[10]: <matplotlib.image.AxesImage object at 0x1416430>
In [11]: cbook.report_memory()
Out[11]: 254624
In [12]: len(ax.images)
Out[12]: 1
In [13]: gc.collect()
Out[13]: 12
Don't know what to do with the 12 though?
If I do the same with a script like this:
from matplotlib.pylab import *
import matplotlib.cbook as cbook
data = ones((1500,1500,3))
imshow(data)
ax = gca()
print cbook.report_memory()
print len(ax.images)
hold(False)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
This is what happens:
81920
1
82028
1
82128
1
82128
1
82132
1
So it's fine here.
So what's wrong with my ipython/pylab? :(
BR,
Michael
|
|
From: John H. <jd...@gm...> - 2010-07-14 16:45:42
|
On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye <kmi...@gm...> wrote: > Out[12]: 1 > > In [13]: gc.collect() > > Out[13]: 12 still not seeing a leak in your data -- you need to report_memory after calling gc collect. Turn off hold, add an image, call collect, report memory, the repeat several times, each time calling collect and report memory, and report the results. JDH |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-14 16:51:54
|
On 2010-07-14 18:45:35 +0200, John Hunter said: > On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye > <kmi...@gm...> wrote: > >> Out[12]: 1 >> >> In [13]: gc.collect() >> >> Out[13]: 12 > > > still not seeing a leak in your data -- you need to report_memory > after calling gc collect. Turn off hold, add an image, call collect, > report memory, the repeat several times, each time calling collect and > report memory, and report the results. Was just following your example, you were nowhere calling collect. Here is what you requested: In [1]: import gc In [2]: import matplotlib.cbook as cbook In [3]: data = ones((1500,1500,3)) In [4]: hold(False) In [5]: imshow(data) Out[5]: <matplotlib.image.AxesImage object at 0x1c43e50> In [6]: gc.collect() Out[6]: 12 In [7]: cbook.report_memory() Out[7]: 174540 In [8]: imshow(data) Out[8]: <matplotlib.image.AxesImage object at 0x1c59e90> In [9]: gc.collect() Out[9]: 0 In [10]: cbook.report_memory() Out[10]: 253400 In [11]: imshow(data) Out[11]: <matplotlib.image.AxesImage object at 0x1c603b0> In [12]: gc.collect() Out[12]: 0 In [13]: cbook.report_memory() Out[13]: 333360 In [14]: imshow(data) Out[14]: <matplotlib.image.AxesImage object at 0x1c60410> In [15]: gc.collect() Out[15]: 0 In [16]: cbook.report_memory() Out[16]: 413296 |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-14 17:12:21
|
On 2010-07-14 18:51:26 +0200, K.-Michael Aye said: > On 2010-07-14 18:45:35 +0200, John Hunter said: > >> On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye >> <kmi...@gm...> wrote: >> >>> Out[12]: 1 >>> >>> In [13]: gc.collect() >>> >>> Out[13]: 12 >> >> >> still not seeing a leak in your data -- you need to report_memory >> after calling gc collect. Turn off hold, add an image, call collect, >> report memory, the repeat several times, each time calling collect and >> report memory, and report the results. > > Was just following your example, you were nowhere calling collect. > Here is what you requested: > > In [1]: import gc > > In [2]: import matplotlib.cbook as cbook > > In [3]: data = ones((1500,1500,3)) > > In [4]: hold(False) > > In [5]: imshow(data) > > Out[5]: <matplotlib.image.AxesImage object at 0x1c43e50> > > In [6]: gc.collect() > > Out[6]: 12 > > In [7]: cbook.report_memory() > > Out[7]: 174540 > > In [8]: imshow(data) > > Out[8]: <matplotlib.image.AxesImage object at 0x1c59e90> > > In [9]: gc.collect() > > Out[9]: 0 > > In [10]: cbook.report_memory() > > Out[10]: 253400 > > In [11]: imshow(data) > > Out[11]: <matplotlib.image.AxesImage object at 0x1c603b0> > > In [12]: gc.collect() > > Out[12]: 0 > > In [13]: cbook.report_memory() > > Out[13]: 333360 > > In [14]: imshow(data) > > Out[14]: <matplotlib.image.AxesImage object at 0x1c60410> > > In [15]: gc.collect() > > Out[15]: 0 > > In [16]: cbook.report_memory() > > Out[16]: 413296 > Here are the commands as macro form, for easy cut and paste into pylab: import gc import matplotlib.cbook as cbook data = ones((1500,1500,3)) hold(False) imshow(data) gc.collect() cbook.report_memory() imshow(data) gc.collect() cbook.report_memory() imshow(data) gc.collect() cbook.report_memory() imshow(data) gc.collect() cbook.report_memory() > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-16 11:32:41
|
On 2010-07-14 19:11:58 +0200, K.-Michael Aye said: > On 2010-07-14 18:51:26 +0200, K.-Michael Aye said: > >> On 2010-07-14 18:45:35 +0200, John Hunter said: >> >>> On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye >>> <kmi...@gm...> wrote: >>> >>>> Out[12]: 1 >>>> >>>> In [13]: gc.collect() >>>> >>>> Out[13]: 12 >>> >>> >>> still not seeing a leak in your data -- you need to report_memory >>> after calling gc collect. Turn off hold, add an image, call collect, >>> report memory, the repeat several times, each time calling collect and >>> report memory, and report the results. >> >> Was just following your example, you were nowhere calling collect. >> Here is what you requested: >> >> In [1]: import gc >> >> In [2]: import matplotlib.cbook as cbook >> >> In [3]: data = ones((1500,1500,3)) >> >> In [4]: hold(False) >> >> In [5]: imshow(data) >> >> Out[5]: <matplotlib.image.AxesImage object at 0x1c43e50> >> >> In [6]: gc.collect() >> >> Out[6]: 12 >> >> In [7]: cbook.report_memory() >> >> Out[7]: 174540 >> >> In [8]: imshow(data) >> >> Out[8]: <matplotlib.image.AxesImage object at 0x1c59e90> >> >> In [9]: gc.collect() >> >> Out[9]: 0 >> >> In [10]: cbook.report_memory() >> >> Out[10]: 253400 >> >> In [11]: imshow(data) >> >> Out[11]: <matplotlib.image.AxesImage object at 0x1c603b0> >> >> In [12]: gc.collect() >> >> Out[12]: 0 >> >> In [13]: cbook.report_memory() >> >> Out[13]: 333360 >> >> In [14]: imshow(data) >> >> Out[14]: <matplotlib.image.AxesImage object at 0x1c60410> >> >> In [15]: gc.collect() >> >> Out[15]: 0 >> >> In [16]: cbook.report_memory() >> >> Out[16]: 413296 >> > > > Here are the commands as macro form, for easy cut and paste into pylab: > > import gc > import matplotlib.cbook as cbook > data = ones((1500,1500,3)) > hold(False) > imshow(data) > gc.collect() > cbook.report_memory() > imshow(data) > gc.collect() > cbook.report_memory() > imshow(data) > gc.collect() > cbook.report_memory() > imshow(data) > gc.collect() > cbook.report_memory() Furthermore, deleting images from ax.images does not free memory : In [1]: import gc In [2]: import matplotlib.cbook as cbook In [3]: data = ones((1500,1500,3)) In [4]: imshow data ------> imshow(data) Out[4]: <matplotlib.image.AxesImage object at 0x1c57550> In [5]: imshow data ------> imshow(data) Out[5]: <matplotlib.image.AxesImage object at 0x1c442b0> In [6]: imshow data ------> imshow(data) Out[6]: <matplotlib.image.AxesImage object at 0x1400cd0> In [7]: imshow data ------> imshow(data) Out[7]: <matplotlib.image.AxesImage object at 0x1414cb0> In [8]: ax =gca() In [9]: ax.images Out[9]: [<matplotlib.image.AxesImage object at 0x1c57550>, <matplotlib.image.AxesImage object at 0x1c442b0>, <matplotlib.image.AxesImage object at 0x1400cd0>, <matplotlib.image.AxesImage object at 0x1414cb0>] In [10]: gc.collect() Out[10]: 15 In [11]: cbook.report_memory() Out[11]: 414588 In [12]: del ax.images[:-1] In [13]: gc.collect() Out[13]: 3 In [14]: cbook.report_memory() Out[14]: 414600 |
|
From: Eric F. <ef...@ha...> - 2010-07-16 16:48:57
|
On 07/16/2010 01:32 AM, K.-Michael Aye wrote: > On 2010-07-14 19:11:58 +0200, K.-Michael Aye said: > >> On 2010-07-14 18:51:26 +0200, K.-Michael Aye said: >> >>> On 2010-07-14 18:45:35 +0200, John Hunter said: >>> >>>> On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye >>>> <kmi...@gm...> wrote: >>>> >>>>> Out[12]: 1 >>>>> >>>>> In [13]: gc.collect() >>>>> >>>>> Out[13]: 12 >>>> >>>> >>>> still not seeing a leak in your data -- you need to report_memory >>>> after calling gc collect. Turn off hold, add an image, call collect, >>>> report memory, the repeat several times, each time calling collect and >>>> report memory, and report the results. >>> >>> Was just following your example, you were nowhere calling collect. >>> Here is what you requested: >>> >>> In [1]: import gc >>> >>> In [2]: import matplotlib.cbook as cbook >>> >>> In [3]: data = ones((1500,1500,3)) >>> >>> In [4]: hold(False) >>> >>> In [5]: imshow(data) >>> >>> Out[5]:<matplotlib.image.AxesImage object at 0x1c43e50> >>> >>> In [6]: gc.collect() >>> >>> Out[6]: 12 >>> >>> In [7]: cbook.report_memory() >>> >>> Out[7]: 174540 >>> >>> In [8]: imshow(data) >>> >>> Out[8]:<matplotlib.image.AxesImage object at 0x1c59e90> >>> >>> In [9]: gc.collect() >>> >>> Out[9]: 0 >>> >>> In [10]: cbook.report_memory() >>> >>> Out[10]: 253400 >>> >>> In [11]: imshow(data) >>> >>> Out[11]:<matplotlib.image.AxesImage object at 0x1c603b0> >>> >>> In [12]: gc.collect() >>> >>> Out[12]: 0 >>> >>> In [13]: cbook.report_memory() >>> >>> Out[13]: 333360 >>> >>> In [14]: imshow(data) >>> >>> Out[14]:<matplotlib.image.AxesImage object at 0x1c60410> >>> >>> In [15]: gc.collect() >>> >>> Out[15]: 0 >>> >>> In [16]: cbook.report_memory() >>> >>> Out[16]: 413296 >>> >> >> >> Here are the commands as macro form, for easy cut and paste into pylab: >> >> import gc >> import matplotlib.cbook as cbook >> data = ones((1500,1500,3)) >> hold(False) >> imshow(data) >> gc.collect() >> cbook.report_memory() >> imshow(data) >> gc.collect() >> cbook.report_memory() >> imshow(data) >> gc.collect() >> cbook.report_memory() >> imshow(data) >> gc.collect() >> cbook.report_memory() > > Furthermore, > deleting images from ax.images does not free memory : Maybe because ipython is keeping a reference to every AxesImage object that you make... Eric > > In [1]: import gc > > In [2]: import matplotlib.cbook as cbook > > In [3]: data = ones((1500,1500,3)) > > In [4]: imshow data > ------> imshow(data) > > Out[4]:<matplotlib.image.AxesImage object at 0x1c57550> > > In [5]: imshow data > ------> imshow(data) > > Out[5]:<matplotlib.image.AxesImage object at 0x1c442b0> > > In [6]: imshow data > ------> imshow(data) > > Out[6]:<matplotlib.image.AxesImage object at 0x1400cd0> > > In [7]: imshow data > ------> imshow(data) > > Out[7]:<matplotlib.image.AxesImage object at 0x1414cb0> > > In [8]: ax =gca() > > In [9]: ax.images > > Out[9]: > [<matplotlib.image.AxesImage object at 0x1c57550>, > <matplotlib.image.AxesImage object at 0x1c442b0>, > <matplotlib.image.AxesImage object at 0x1400cd0>, > <matplotlib.image.AxesImage object at 0x1414cb0>] > > In [10]: gc.collect() > > Out[10]: 15 > > In [11]: cbook.report_memory() > > Out[11]: 414588 > > In [12]: del ax.images[:-1] > > In [13]: gc.collect() > > Out[13]: 3 > > In [14]: cbook.report_memory() > > Out[14]: 414600 > |
|
From: K.-Michael A. <kmi...@gm...> - 2010-07-20 09:59:30
|
On 2010-07-16 18:48:48 +0200, Eric Firing said: >> >> Furthermore, >> deleting images from ax.images does not free memory : > > Maybe because ipython is keeping a reference to every AxesImage object > that you make... > > Eric Well, maybe, but why does it not happen for John? His penultimate post showed, that his iPython session does not have this problem? Is there a setting that might influence this apart from the hold state? Michael |
|
From: Eric F. <ef...@ha...> - 2010-07-20 17:16:44
|
On 07/19/2010 11:59 PM, K.-Michael Aye wrote: > On 2010-07-16 18:48:48 +0200, Eric Firing said: > >>> >>> Furthermore, >>> deleting images from ax.images does not free memory : >> >> Maybe because ipython is keeping a reference to every AxesImage object >> that you make... >> >> Eric > > Well, maybe, but why does it not happen for John? His penultimate post > showed, that his iPython session does not have this problem? Is there a > setting that might influence this apart from the hold state? My suggestion was wrong, and I'm baffled. Running your set of commands with your matplotlibrc (so that tkagg is used), I don't see the change in memory consumption. Maybe it is a problem with tk on the mac. Or something that was changed between 0.99.3 and 1.0. Eric > > Michael > |
