The attached script gives a quick and simple illustration of the pdf backend memory leak noted earlier by Paul Kienzle. It seems to be entirely related to rendering text. Adding axes, lines, and images does not seem to matter, except insofar as adding an axes will trigger the rendering of text for the tick labels. The leak per loop is roughly proportional to the number of *different* characters being rendered--about 100 bytes per character.
I don't think I could find the leak in any reasonable time; I hope someone else who is more familiar with the pdf backend and more clever at such things will be able to track it down ASAP.
Eric
memleak_minimal.py (865 Bytes)
In the past, if I recall correctly, these leaks have been in ttconv,
which is Michael's area of expertise, so let's see if he has any
flashes of insight Monday... If this is the case it would likely
affect ps and pdf but not the other backends.
JDH
···
On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <efiring@...229...> wrote:
The attached script gives a quick and simple illustration of the pdf backend
memory leak noted earlier by Paul Kienzle. It seems to be entirely related
to rendering text. Adding axes, lines, and images does not seem to matter,
except insofar as adding an axes will trigger the rendering of text for the
tick labels. The leak per loop is roughly proportional to the number of
*different* characters being rendered--about 100 bytes per character.
I don't think I could find the leak in any reasonable time; I hope someone
else who is more familiar with the pdf backend and more clever at such
things will be able to track it down ASAP.
I'm just getting back from vacation and will add this to my TODO list. I have some thoughts...
Cheers,
Mike
Eric Firing wrote:
···
John Hunter wrote:
On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <efiring@...229...> wrote:
The attached script gives a quick and simple illustration of the pdf backend
memory leak noted earlier by Paul Kienzle. It seems to be entirely related
to rendering text. Adding axes, lines, and images does not seem to matter,
except insofar as adding an axes will trigger the rendering of text for the
tick labels. The leak per loop is roughly proportional to the number of
*different* characters being rendered--about 100 bytes per character.
I don't think I could find the leak in any reasonable time; I hope someone
else who is more familiar with the pdf backend and more clever at such
things will be able to track it down ASAP.
In the past, if I recall correctly, these leaks have been in ttconv,
which is Michael's area of expertise, so let's see if he has any
flashes of insight Monday... If this is the case it would likely
affect ps and pdf but not the other backends.
JDH
The ps backend leak with this test is about 70 bytes/loop, and the same with either 20 or 10 characters, so it may have a different origin than the pdf leak; with no suptitle at all, the ps backend leak is 0. svg and agg are both 0 in this test (with suptitle included).
Eric
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Yes, it looks like _ttconv.cpp is the culprit here. Sloppy reference handling (and I say that as the author of that file...) I've committed some changes to SVN that seem to remove the leaks with memleak_hawaii3.py and the PDF and PS backends.
Cheers,
Mike
Michael Droettboom wrote:
···
I'm just getting back from vacation and will add this to my TODO list. I have some thoughts...
Cheers,
Mike
Eric Firing wrote:
John Hunter wrote:
On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <efiring@...229...> wrote:
The attached script gives a quick and simple illustration of the pdf backend
memory leak noted earlier by Paul Kienzle. It seems to be entirely related
to rendering text. Adding axes, lines, and images does not seem to matter,
except insofar as adding an axes will trigger the rendering of text for the
tick labels. The leak per loop is roughly proportional to the number of
*different* characters being rendered--about 100 bytes per character.
I don't think I could find the leak in any reasonable time; I hope someone
else who is more familiar with the pdf backend and more clever at such
things will be able to track it down ASAP.
In the past, if I recall correctly, these leaks have been in ttconv,
which is Michael's area of expertise, so let's see if he has any
flashes of insight Monday... If this is the case it would likely
affect ps and pdf but not the other backends.
JDH
The ps backend leak with this test is about 70 bytes/loop, and the same with either 20 or 10 characters, so it may have a different origin than the pdf leak; with no suptitle at all, the ps backend leak is 0. svg and agg are both 0 in this test (with suptitle included).
Eric
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
initial tests look good on my end. thanks!
JDH
···
On Thu, Jul 31, 2008 at 10:37 AM, Michael Droettboom <mdroe@...31...> wrote:
Yes, it looks like _ttconv.cpp is the culprit here. Sloppy reference
handling (and I say that as the author of that file...) I've committed some
changes to SVN that seem to remove the leaks with memleak_hawaii3.py and the
PDF and PS backends.