Mike,
On my machine, with pcolor from the trunk:
[EMAIL PROTECTED]:~/test$ python pcolortest2.py
init: 2.0
fps: 0.287026406429
And substituting pcolormesh for pcolor:
init: 0.27
fps: 5.48245614035
Now that's more like it!
Using image can be another order of magnitude faster than pcolormesh
(
Michael Droettboom wrote:
> Eric Firing wrote:
>> Mike,
>>
>> Thanks for the quick response.
>>
>> I was wrong as usual: the masked array overhead in your original
>> version of the path initializer was actually small. I misinterpreted
>> the kcachegrind display. Rats! I was hoping for a big g
Attaching benchmark.
from numpy.random import rand
import matplotlib
from matplotlib.pyplot import pcolor, savefig, show, ion, axis, draw, axes
import time
ion()
t = time.clock()
pcolor(rand(1000,100))
print "init: ", time.clock() - t
frames = 25.0
t = time.clock()
for i in xrange(int(frames))
Eric Firing wrote:
> Mike,
>
> Thanks for the quick response.
>
> I was wrong as usual: the masked array overhead in your original version
> of the path initializer was actually small. I misinterpreted the
> kcachegrind display. Rats! I was hoping for a big gain. It looks like
> anything t
Mike,
Thanks for the quick response.
I was wrong as usual: the masked array overhead in your original version
of the path initializer was actually small. I misinterpreted the
kcachegrind display. Rats! I was hoping for a big gain. It looks like
anything that makes a huge number of paths is
Eric Firing wrote:
> Mike,
>
> I made a quick test and took a quick look, and I certainly see a ripe
> mango within reach. I don't know what your constraints and strategy
> are, but I thought I would give you the off-the-cuff idea before I
> forget what I did.
>
> The test was pcolortest.py,
