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, one line is expensive: val = > ma.array(clip(val.filled(vmax), vmin, vmax), mask=mask). If I put a test > on mask when mask is None (which it is in my case), then the function > becomes negligeable. > - for colormap functor, the 3 where calls are expensive. I am not > sure to understand in which case they are useful; if I understand > correctly, one tries to avoid > values out of range (0, N), and force out of range values to be clipped. > Isn't there an easier way than using where ? > > If I remove the where in the colormap functor, I have a 4x speed > increase for the to_rgba function. After that, it becomes a bit more > tricky to change things for someone like me who have no knowledge about > matplotlib internals. The things you have identified were added by me to support masked array bad values and special colors for regions above or below the mapped range of values. I will be happy to make changes to speed them up. 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 surprised it is a bottleneck; in any case I can take a look to see how it can be sped up, or whether it can be bypassed in some cases. Maybe it is also using "where" internally. Now I recall very recent discussion explaining why "where" is slow compared to indexing with a boolean, so I know I can speed it up with numpy. Unfortunately Numeric does not support this, so maybe what will be needed is numerix functions that take advantage of numpy when available. This is one of those times when I really wish we could drop Numeric and numarray support *now* and start taking full advantage of numpy. In any case, thanks for pointing out the slowdowns--I will fix them as best I can--and keep at it. I share your interest in speeding up interactive use of matplotlib, along with fixing bugs, filling holes in functionalisy, and smoothing rough edges. There is a lot to be done. As John noted, though, there will always be tradeoffs among flexibility, code simplicity, generality, and speed. Eric ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
