changes to pcolor function

Dr. Kienzle,

Did you get my message before about improving the pcolor function by changing the way the "verts" array is created? Although I couldn't get it to work on my machine (maybe because I'm not actually re-building it, I'm just editing the source file and then exiting and restarting) someone else on the mailing list said he didn't have problems. If you can, make those changes and report back to me on how wll they work.
Also, is it just the "pcolor" function that is too slow or is the "draw" function too slow as well?

-Alex Mont


----- Original Message ----- From: "Paul Kienzle" <pkienzle@...870...>
To: "John Hunter" <jdhunter@...8...>
Cc: "Alexander Mont" <alexmont1@...614...>; <>
Sent: Thursday, November 03, 2005 11:10 AM
Subject: Re: [Matplotlib-users] Memory leak with pcolor

On Tue, Nov 01, 2005 at 09:41:35PM -0600, John Hunter wrote:

    > Thanks for your advice with installing matplotlib on
    > cygwin. I downloaded and installed the windows binaries
    > and it worked. Anyway, the reason that I didn't want
    > to use binaries in the first place was because I wanted
    > to modify the matplotilb source code. But it seems like
    > even with the binaries, if I change the source code
    > then it will still affect the operation of the program
    > when I run it, which is what I want.

    > In particular, I am looking to speed up the pcolor()
    > function because it runs exceedingly slow with large
    > mesh sizes. I believe the reason it is running slow is
    > because of a memory leak. When I do the following:

    > from pylab import * n=200
    > [x,y]=meshgrid(arange(n+1)*1./n,arange(n+1)*1./n)
    > z=sin(x**2 + y**2)

    > and then do

    > pcolor(x,y,z)

    > repeatedly, the memory usage increases by about 15 MB
    > each time, and it runs progressively slower.each

At least with matplotlib CVS (and I don't think it's a CVS vs 0.84
issue) the memory consumption is rock solid with your example (see
below for my test script). What is your default "hold" setting in rc?
If True, you will be overlaying plots and will get the behavior you
describe. In the example below, I make sure to "close" the figure
each time -- a plain clear with clf should suffice though. My guess
is that you are repeatedly calling pcolor with hold : True and are
simply overlaying umpteen pcolors (to test for this, print the length
of the collections list

  ax = gca()
  print len(ax.collections)

if this length is growing, you've found your problem. A simple


should suffice.

You can also change the default hold setting in your config file


I can confirm that memory leaks indeed are not a problem with a CVS build
on Debian. I can't seem to restore the pre-built Debian stable 0.82 so
I haven't tested it.

However, the problem is still that pcolor is too slow to use it
interactively on a plot with a half-dozen 200x608 warped grids, even
with shading='flat' and no antialiasing.

Would you consider accepting a 'structured grid' as a primitive patch
type? What consequence will this have for your various backends?
Presumably someone will want triangular meshes as well if they are
doing serious FEM work.

I created a prototype app using OpenGL and quad strips. The performance
with this is acceptable, but I need a lot more 2D graphing features.
I would much rather make an existing product better than rewrite from

In my particular case the grid warping function can be expressed
analytically. Is it reasonable to consider warping a 2D image directly
using an AGG filter function? Could this be embedded in an existing
matplotlib graph, above some objects and below others?

Thanks in advance,

Paul Kienzle

SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play:
Matplotlib-users mailing list
matplotlib-users List Signup and Options