Repository navigation
memory leak when using pcolormesh with pylab inline #3508
Description
A minimal script that reproduces the problem (this took a long time to pinpoint!! ;) ):
%pylab inline
x = randn(20)
y = randn(20)
fig, axes = subplots(8, 12)
for loc, ax in ndenumerate(axes):
counts_hist, xedges, yedges = histogram2d(x, y, bins=200)
ax.pcolormesh(xedges, yedges, counts_hist)Running this script in matplotlib (1.4.x) / ipython notebook 2.1.0 / 2.2.0 and numpy v1.9.0 produces a memory leak when using inline mode.
Specifically, it eats up ~5.5 GB of memory on my machine.
If I don't use the inline mode everything works fine. (I got a similar result on another machine.. both running ubuntu 14.04 and matplotlib/ipython installed from pip)
This is not an issue using matplotlib 1.3.1, so I think it's something in the new update.
I'll be glad to help with any additional information that you think would be helpful!
Activity
WeatherGod commentedon Sep 13, 2014
Some points to make here...
First, I seriously doubt there is any actual memory leak here. IPython
likes to save the results of just about every function call that doesn't
save its output itself. So, those pcolormeshes are building up over time
in a given session. IPython also does some funky stuff with pylab inline
mode that might be complicating things a bit.
Now, that isn't to say that changes may have happened for there to be more
memory used in matplotlib, but this alone is not evidence of a memory leak
(indeed, 96 axes of 20x20 data is still only 38400 points; I just don't see
that ending up being 5.5 GB). I would be curious to see if this would
happen in a regular script rather than in IPython.
Second, try hexbin instead, or hist2d.
Ben Root
On Fri, Sep 12, 2014 at 9:36 PM, Eugene Yurtsev notifications@github.com
wrote:
eyurtsev commentedon Sep 13, 2014
Hi Ben,
The script above works fine if I run it as a regular script. The issue only appears when I use ipython in inline mode.
hist2d and hexbin work fine in pylab inline mode, so the problem only appears with pcolormesh.
Eugene.
tacaswell commentedon Sep 13, 2014
If it runs fine as a regular script, then that points to this being an ipython issue, not an mpl issue.
cc @takluyver as the ipython dev I have talked to the most. Can you forward this to the correct person on your side?
michaelaye commentedon Sep 14, 2014
I guess it would be helpful to know what changes from 1.3 to 1.4 could lead to an iPython problem being not exposed in one but being exposed in the other version?
pelson commentedon Sep 23, 2014
I'm not convinced it is related, but the following may be relevant #3095.
takluyver commentedon Sep 24, 2014
I'm not sure what IPython could be doing that involves this. Is it possible that the standalone script uses 5.5GB but it's then freed quickly, whereas IPython holds onto it?
IPython's inline backend can be seen here - I don't know enough about mpl to know what gets called when.
https://github.com/ipython/ipython/blob/master/IPython/kernel/zmq/pylab/backend_inline.py
tacaswell commentedon Nov 26, 2014
Closing in favor of #3095 where the issue (use of a tight bounding box on save) is sorted out.