Re: [matplotlib-devel] Possible Bug

[Joe <gar...@us...>]

Thanks John,

Sheesh, 95 degrees, I can't imagine how I'd take that.   Some Christmases my 
family would go visit relatives in Chicago.  It seemed just a little bit more 
warmer (but not that much) when we returned to Oklahoma.  Never really gone 
anywhere to warm for Christmas.

More below...

On Tuesday 18 January 2005 20:25, John Hunter wrote:
> >>>>> "Joe" == Joe  <gar...@us...> writes:
>
>     Joe> Hello devels, I chose to use matplotlib for a restaurant
>     Joe> simulation.  It supplied all the features I needed and I was
>     Joe> pleasantly surprised.  However the people I was doing this
>     Joe> project for mentioned that the simulation slowed down to a
>     Joe> crawl 10 or so minutes into the simulation.  It sounded like
>     Joe> a memory leak to me so I investigated and found a 100 KB/sec
>     Joe> leak in Windows (via the interpreter as well as frozen with
>     Joe> py2exe) as well as in Linux.  I narrowed it down to a part of
>     Joe> the code where I updated xlim and ylim via Axes::set_xlim,
>     Joe> Axes::set_ylim.  Commenting that part out yielded no leak,
>
> So you're doing animation right?  Are you using images, eg imshow?  I
> just fixed a memory leak in image resizing that amounts to about
> 200K/resize -- the changes are in CVS.  Of course on windows it's hard
> to test because the changes are in extension code, and require
> building on win32.  The instructions for building on win32 are in the
> file setupext.py.

I wish so, but no, I'm not using any images.

> If you are not using images, another place to look is in text caching.
> text layout is expensive (to support arbitrary rotations, etc).  So I
> cache the layout information in a dictionary "cached" in the text
> module.  When you change the xlim/ylim, that would trigger a new
> layout and an addition to the cache.  We need to add some
> auto-clearing mechanisms to prevent the cache from growing w/o bound
> but its not done yet.  I find it hard to believe, though, that this
> would leak 100kb/sec.  Assuming a 20Hz frame rate, the leak is about
> 5kb/sec, and I don't think I'm caching that much info.

I am using 5 GTKAgg FIgure widgets with 2-3 subplots a piece (a maximum of 3 
subplots get drawn at a time).  The simulation runs at 1 Hz.  Therefore 6.67 
kB/sec at max.  Which sounds about right.  I am updating each Axes point set 
when I do the update.  

> You can estimate the memory effect of the cached simply by commenting
> out the line
>
>         self.cached[key] = ret
>
> in the matplotlib.text module.

I'll definitely check that out.  With the above math that just might prove to 
be the culprit.

> What backend are you using?  Are you refreshing the same figure data,
> or creating new figures?  More information would certainly help.....
>
>     Joe> however I lost some critical functionality in my charts
>     Joe> (which behave like the Windows Task Manager resource monitor
>     Joe> graphs).  So I really need this fixed.  I will send shortly a
>     Joe> test case which replicates the problem.
>
> That would be great.
>
>     Joe> Since the maintainer is out on vacation, I was also wondering
>     Joe> if anyone knew enough about the internals of matplotlib that
>     Joe> they could give me an idea of which modules (Python or
>     Joe> otherwise) are affected by Axes::set_xlim and Axes::set_ylim.
>
> I'm back.  I was in Rio for a couple of weeks and have suffered a 95
> degree temperature drop returning to Chicago (sigh)...
>
> JDH

I'll get the test case up on the web ASAP, I just wanted to reply now to let 
everyone know that I'm still working on the problem.

Joe