Thanks again for your help!
I can confirm that your patch works, and appreciate it. I'm almost surprised that I'd be one of the few running codes that would find a problem such as this, with plotting repeatedly over a large number of iterations.
Thanks for making a runnable example.
It was quite a puzzle, but I tracked it down to leaking references on
"Glyph" objects (they store little bits of descriptive information about
characters in a font.) The leak was actually rather small, and I think
you came across it because of the high number of iterations you were
doing and also the largish amount of text in your plots.
If you're curious, I've attached the output from valgrind's "massif"
tool from before and after my fix. You can see from this that the leak
was a very small percentage of the overall memory usage.
The patch to fix (SVN r4918) is simple, and I'll forward it to you
off-list. It will be included when/if we do a 0.91.3 release.
Aaron Botnick wrote:> Mike,
> In response to your questions, yes, I meant to say MPL version 0.91.2.
> I believe the objects were lists and dictionaries, and they appeared to
> be related to plotting parameters, such as those found in rcParams.
> I'm now including a gzipped tar file that includes one instance of the
> sample data, and the input file slicer.dat, that will have the program
> use this sample data for 512 iterations. The plots will appear in the
> plots directory, but will be overwritten each time. I checked briefly,
> and I believe the memory usage problem remains with this variant, as the
> main code itself has not changed. So long as the OS doesn't cache the
> data files, it should be nearly identical to running on the original data.
> Just unzip and run 'slicer_mpl.py' with the optional argument of slicer.dat.
> Hopefully that works for you. Thanks again.
> -- Aaron--
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA