R: [Gdal-dev] trivial (?) optimization for gdal.i:GDALReadRaster( )
alexamici at fastwebnet.it
Wed Feb 4 17:18:04 EST 2004
> > [...] however, to
> > the best of my knowledge there isn't any reason these couldn't both be
> > supported is there?
> in principle no.
> in practice i can easily see the maintainace cost to climb quite high.
it actually depends on how you do it. if you only want configure time choice
between Numeric and numarray you mostly have to s/Numeric/numarray/g inside
a first try at a zero-copy implementation with numarray gave me (same program
as before) the quite amazing numbers below:
CPU: CPU with timer interrupt, speed 1000.15 MHz (estimated)
Profiling through timer interrupt
vma samples % app name symbol name
001323b0 8026 49.8355 libgdal.so.1.1.9 GDALCopyWords
c01b0310 2180 13.5362 vmlinux __copy_to_user_ll
00077990 1583 9.8292 libc-2.3.2.so memcpy
c01afdf0 1322 8.2086 vmlinux fast_clear_page
001322d0 849 5.2717 libgdal.so.1.1.9 GDALSwapWords
00000000 304 1.8876 python2.3 (no symbols)
which means that the overhead of using python instead of C for reading a 500Mb
image with gdal wuold be a bare 2% of cpu time!
IMHO looking at numarray is definetly worth.
More information about the Gdal-dev