Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-20 Thread David Cournapeau
John Hunter wrote: > > > David> In make_image, most of the time is taken into to_rgba: > David> almost half of it is taken in by the take call in the > David> Colormap.__call__. Almost 200 ms to get colors from the > David> indexes seems quite a lot (this means 280 cycles / pixel on

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-19 Thread John Hunter
> "David" == David Cournapeau <[EMAIL PROTECTED]> writes: David> In make_image, most of the time is taken into to_rgba: David> almost half of it is taken in by the take call in the David> Colormap.__call__. Almost 200 ms to get colors from the David> indexes seems quite a lot

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-18 Thread David Cournapeau
David Cournapeau wrote: > Eric Firing wrote: >> There is a clip function in all three numeric packages, so a native >> clip is being used. >> >> If numpy.clip is actually slower than your version, that sounds like a >> problem with the implementation in numpy. By all logic a single clip >> func

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-17 Thread David Cournapeau
Eric Firing wrote: > > There is a clip function in all three numeric packages, so a native > clip is being used. > > If numpy.clip is actually slower than your version, that sounds like a > problem with the implementation in numpy. By all logic a single clip > function should either be the same

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-17 Thread Eric Firing
David Cournapeau wrote: [...] > Ok, I've installed last svn, and now, there is still one function which > is much slower than a direct numpy implementation, so I would like to > know if this is inherent to the multiple backend nature of matplotlib or > not. The functor Normalize uses the clip fu

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-17 Thread David Cournapeau
Eric Firing wrote: > David, > > I have made some changes in svn that address all but one of the points > you made: > > [] >> if self.clip: >>mask = ma.getmaskorNone(val) >>if mask == None: >>val = ma.array(clip(val.filled(vmax), vmin, vmax))

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-14 Thread Eric Firing
David, I have made some changes in svn that address all but one of the points you made: [] > if self.clip: >mask = ma.getmaskorNone(val) >if mask == None: >val = ma.array(clip(val.filled(vmax), vmin, vmax)) >else: >

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-13 Thread David Cournapeau
Eric Firing wrote: > > Regarding the clip line, I think that your test for mask is None is > not the right solution because it knocks out the clipping operation, > but the clipping is intended regardless of the state of the mask. I > had expected it to be a very fast operation, so I am surpris

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-13 Thread Christopher Barker
Eric Firing wrote: > Regarding the clip line, I think that your test for mask is None is not > the right solution because it knocks out the clipping operation, but the > clipping is intended regardless of the state of the mask. I had > expected it to be a very fast operation, for what it's wo

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-13 Thread Eric Firing
David, >- first, we can see that in expose_event (one is expensive, the other > negligeable, from my understanding), two calls are pretty expensive: > the __call__ at line 735 (for normalize functor) and one for __call__ > at line 568 (for colormap functor). >- for normalize functor, o

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-13 Thread David Cournapeau
David Cournapeau wrote: > But the show case is more interesting: > > ncalls tottime percall cumtime percall filename:lineno(function) > 10.0020.0023.8863.886 > slowmatplotlib.py:177(bench_imshow_show) > 10.0000.0003.8843.884 > slowmatplotlib.py:163

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-12 Thread David Cournapeau
John Hunter wrote: This is where you can help us. Saying specgram is slow is only marginally more useful than saying matplotlib is slow or python is slow. What is helpful is to post a complete, free-standing script that we can run, with some attached performance numbers. For starters, just run

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-12 Thread Fernando Perez
On 12/12/06, John Hunter <[EMAIL PROTECTED]> wrote: > --verbose-helpful will confirm the setting). A good way to start is > to write a demonstration script that you find too slow which makes a > call to savefig, and run it with > > > time myscript.py --verbose-helpful -dAgg It may be worth men

Re: [Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-12 Thread John Hunter
> "David" == David Cournapeau <[EMAIL PROTECTED]> writes: David> Hi, I am a regular user of matplotlib since I moved from David> matlab to python/numpy/scipy. Even if I find matplotlib to David> be a real help during the transition from matlab to python, David> I must confess I

[Matplotlib-users] Some remarks/questions about perceived slowness of matplotlib

2006-12-12 Thread David Cournapeau
Hi, I am a regular user of matplotlib since I moved from matlab to python/numpy/scipy. Even if I find matplotlib to be a real help during the transition from matlab to python, I must confess I found it the most disappointing compare other packages ( essentially numpy/scipy/ipython). This i