Hello to all,
This is yet another question about matplotlib not freeing memory, when closing a figure (using close()).
Here is what I'm doing (tried with several backends, on MacOSX and Linux, with similar results):
···
--------------------
import matplotlib as mpl
from matplotlib import pylot as plt
import numpy as np
a = np.arange(1000000)
mpl.cbook.report_memory()
# -> output: 54256
plt.plot(a)
mpl.cbook.report_memory()
# -> output: 139968
plt.close()
mpl.cbook.report_memory()
# -> output: 138748
--------------------
Shouldn't plt.close() close the figure _and_ free the memory used by it?
What am I doing wrong ?
I tried several other ways to free the memory, such as f = figure(); ... ; del f, without luck.
Any help appreciated !
P.S. : side question : how come the call to plot take so much memory (90MB for a 8MB array ?). I have read somewhere that each point is coded on three RGB floats, but it only means an approx. 12MB plot... (plus small overhead)
Jules
Jules,
Which version of Matplotlib are you using and which backend? On my Linux install of matplotlib (development branch) using GTKAgg, the memory usage does get high during the call to show(), but returns to (near) normal amounts after I close. An interesting observation is that if the interactive mode is off, the memory usage returns back to just a few kilobytes above where it was before, but if interactive mode was turned on, the memory usage returned to being a few hundred kilobytes above where it started.
Ben Root
P.S. - As a side note, estimating the memory size of these plots from the given data isn’t as straight-forward as multiplying by three (actually, it would be four because of the transparency value in addition to rgb). There are many other parts of the graph that needs to be represented (all having rgba values) but there are also a lot of simplifications that are done to reduce the amount of memory needed to represent these objects.
···
On Thu, Jan 13, 2011 at 7:54 AM, CASOLI Jules <jules.casoli@…3117…> wrote:
Hello to all,
This is yet another question about matplotlib not freeing memory, when closing a figure (using close()).
Here is what I’m doing (tried with several backends, on MacOSX and Linux, with similar results):
import matplotlib as mpl
from matplotlib import pylot as plt
import numpy as np
a = np.arange(1000000)
mpl.cbook.report_memory()
→ output: 54256
plt.plot(a)
mpl.cbook.report_memory()
→ output: 139968
plt.close()
mpl.cbook.report_memory()
→ output: 138748
Shouldn’t plt.close() close the figure and free the memory used by it?
What am I doing wrong ?
I tried several other ways to free the memory, such as f = figure(); … ; del f, without luck.
Any help appreciated !
P.S. : side question : how come the call to plot take so much memory (90MB for a 8MB array ?). I have read somewhere that each point is coded on three RGB floats, but it only means an approx. 12MB plot… (plus small overhead)
Jules
You're not doing this from ipython are you? It's cache hangs onto the
plot object references and stops python's garbage collector from
releasing them. If so, you can disable the cache as a workaround. A
better option would be if ipython implemented an option to avoid
caching references to matplotlib objects.
Gary R.
···
On Fri, Jan 14, 2011 at 2:59 AM, Benjamin Root <ben.root@...1304...> wrote:
On Thu, Jan 13, 2011 at 7:54 AM, CASOLI Jules <jules.casoli@...3117...> wrote:
Hello to all,
This is yet another question about matplotlib not freeing memory, when
closing a figure (using close()).
Here is what I'm doing (tried with several backends, on MacOSX and Linux,
with similar results):
--------------------
import matplotlib as mpl
from matplotlib import pylot as plt
import numpy as np
a = np.arange(1000000)
mpl.cbook.report_memory()
# -> output: 54256
plt.plot(a)
mpl.cbook.report_memory()
# -> output: 139968
plt.close()
mpl.cbook.report_memory()
# -> output: 138748
--------------------
Shouldn't plt.close() close the figure _and_ free the memory used by it?
What am I doing wrong ?
I tried several other ways to free the memory, such as f = figure(); ... ;
del f, without luck.
Any help appreciated !
P.S. : side question : how come the call to plot take so much memory (90MB
for a 8MB array ?). I have read somewhere that each point is coded on three
RGB floats, but it only means an approx. 12MB plot... (plus small overhead)
Jules
Jules,
Which version of Matplotlib are you using and which backend? On my Linux
install of matplotlib (development branch) using GTKAgg, the memory usage
does get high during the call to show(), but returns to (near) normal
amounts after I close. An interesting observation is that if the
interactive mode is off, the memory usage returns back to just a few
kilobytes above where it was before, but if interactive mode was turned on,
the memory usage returned to being a few hundred kilobytes above where it
started.
Ben Root
P.S. - As a side note, estimating the memory size of these plots from the
given data isn't as straight-forward as multiplying by three (actually, it
would be four because of the transparency value in addition to rgb). There
are many other parts of the graph that needs to be represented (all having
rgba values) but there are also a lot of simplifications that are done to
reduce the amount of memory needed to represent these objects.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Hooo, well done! This is it.
I didn't knew about caching...
I was indeed using ipython, but I did led some test using the basic python interpreter,with same results, so I did not mention this point.
In fact, python's basic interpreter still records the last three outputs. As my tests were really short (plt.close() ; mpl.cbook.report_memory() ; gc.collect() is only two lines before the collect, only o)ne o,f theme outputt ing something) even pyhton's caching was still at work, and the garbage collector could not free anything.
Thanks a lot, and also thanks to Ben for taking interest !
Jules
PS : Gary, sorry, for the duplicated mail...
···
Le 14 janv. 2011 à 04:04, gary ruben a écrit :
You're not doing this from ipython are you? It's cache hangs onto the
plot object references and stops python's garbage collector from
releasing them. If so, you can disable the cache as a workaround. A
better option would be if ipython implemented an option to avoid
caching references to matplotlib objects.
Gary R.
On Fri, Jan 14, 2011 at 2:59 AM, Benjamin Root <ben.root@...1304...> wrote:
On Thu, Jan 13, 2011 at 7:54 AM, CASOLI Jules <jules.casoli@...3117...> wrote:
Hello to all,
This is yet another question about matplotlib not freeing memory, when
closing a figure (using close()).
Here is what I'm doing (tried with several backends, on MacOSX and Linux,
with similar results):
--------------------
import matplotlib as mpl
from matplotlib import pylot as plt
import numpy as np
a = np.arange(1000000)
mpl.cbook.report_memory()
# -> output: 54256
plt.plot(a)
mpl.cbook.report_memory()
# -> output: 139968
plt.close()
mpl.cbook.report_memory()
# -> output: 138748
--------------------
Shouldn't plt.close() close the figure _and_ free the memory used by it?
What am I doing wrong ?
I tried several other ways to free the memory, such as f = figure(); ... ;
del f, without luck.
Any help appreciated !
P.S. : side question : how come the call to plot take so much memory (90MB
for a 8MB array ?). I have read somewhere that each point is coded on three
RGB floats, but it only means an approx. 12MB plot... (plus small overhead)
Jules
Jules,
Which version of Matplotlib are you using and which backend? On my Linux
install of matplotlib (development branch) using GTKAgg, the memory usage
does get high during the call to show(), but returns to (near) normal
amounts after I close. An interesting observation is that if the
interactive mode is off, the memory usage returns back to just a few
kilobytes above where it was before, but if interactive mode was turned on,
the memory usage returned to being a few hundred kilobytes above where it
started.
Ben Root
P.S. - As a side note, estimating the memory size of these plots from the
given data isn't as straight-forward as multiplying by three (actually, it
would be four because of the transparency value in addition to rgb). There
are many other parts of the graph that needs to be represented (all having
rgba values) but there are also a lot of simplifications that are done to
reduce the amount of memory needed to represent these objects.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
No problem. This caught me out a long time ago and has also caught out
a few people I know.
···
On Fri, Jan 14, 2011 at 8:23 PM, CASOLI Jules <jules.casoli@...3117...> wrote:
Hooo, well done! This is it.
I didn't knew about caching...
I was indeed using ipython, but I did led some test using the basic python interpreter,with same results, so I did not mention this point.
In fact, python's basic interpreter still records the last three outputs. As my tests were really short (plt.close() ; mpl.cbook.report_memory() ; gc.collect() is only two lines before the collect, only o)ne o,f theme outputt ing something) even pyhton's caching was still at work, and the garbage collector could not free anything.
Thanks a lot, and also thanks to Ben for taking interest !
Jules
PS : Gary, sorry, for the duplicated mail...