On 02/09/2011 12:36 PM, Benjamin Root wrote: > On Wed, Feb 9, 2011 at 1:50 AM, Eric Firing <efir...@hawaii.edu > <mailto:efir...@hawaii.edu>> wrote: > > On 02/08/2011 02:39 PM, Christoph Gohlke wrote: > > > > > > > Please consider the attached patch for the _image.frombyte > function. It > > avoids temporary copies in case of non-contiguous input arrays. > Copying > > a 1024x1024 slice out of a contiguous 4096x4096 RGBA or RGB array is > > about 7x faster (a common case for zooming/panning). Copying > contiguous > > RGB input arrays is ~2x faster. Tested on win32-py2.7. > > > > Christoph > > > > Thank you! > > Looks good, speeds up zooming and panning on large images as advertised. > An 8000x8000 image is actually manageable now. > interpolation='nearest' is still very slow until the image is > substantially zoomed, but everything is quite quick with other > interpolation styles. The slowness of 'nearest' looks like a basic > characteristic of the implementation. > > I committed the patch in 8966. > > Before that I found and committed a big speed-up in Normalize. > > Eric > > > Eric, > > How much is the speed-up in Normalize? It might be worth it to apply it > to LogNorm as well. (as an aside, I find the duplication of code in > Normalize and friends a little disconcerting...).
Timing: I don't recall exactly, but it was along the lines of 3.5 seconds getting knocked down to 0.6 seconds. Yes, I will apply it to LogNorm. Duplication: yes, but every time I look at it I see that there are subtle but essential differences here and there, so it does not look worthwhile to try to factor out the remaining commonality. > > Also, what would it take (if it is at all possible) to take advantage of > these image optimizations while using pcolor? The norm and cmap optimizations are already taken advantage of by all color mapping operations. The optimization of using uint8 was already being done in quadmesh, nonuniform image, and pcolor image (all used by pcolorfast). The image.frombyte optimization that Christoph just came up with (8966) is specific to image. There may be some similar optimizations that could be made for other image-like plots (reducing copying and temporaries), but I don't think there will be the same level of payoff. Pcolor itself is hopelessly slow by nature, and should be used only for relatively small arrays. And then there is hexbin, which is *really* slow. It could be sped up with the addition of some cython, but would need a quadmesh-like extension to make it really speedy. (All this is off the top of my head, so I may be misstating a point here and there.) Eric > > Ben Root > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > > > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
