[gdal-dev] GDALRasterBand::RasterIO c++ vs BandReadAsArray python performance

Gareth James Jones [gjj12] gjj12 at aber.ac.uk
Wed May 11 09:53:36 PDT 2016

I'm currently writing optimisations for a raster viewer program which uses gdal as it's base. It's currently written purely in python, and has some major speed issues which cause problems when we are reading many files at a time. After making some optimisations in the python, and getting quite a minimal speed increase, I proceeded to profile the program quite heavily and found that our getImage method was our slowest call. I had already performed some optimisations on this function so decided to write a C-Extension so that we could get some speed increases through a lower level language.

This has worked for the most part, however there is still one issue, we have found a speed increase of ~2s for some of our larger files in the bulk of the code. But this is negated by the GDALRasterIO call, which is actually about 3s slower than the python ReadAsArray.

This doesn't make any sense to me as ReadAsArray is a wrapper around a C++ call to GDALRasterIO, and thus should be slower than having a call straight to GDALRasterIO.

I was hoping someone here might know of a way to read the rasters more efficiently. I have tried to implement a method using ReadBlock rather than RasterIO, but due to the replication that RasterIO does it didn't work at all. (I'm currently trying to figure out a way to do that replication without losing too much speed).

The RasterIO call i'm using is

band->RasterIO(GF_Read, this->ovleft, this->ovtop, this->ovxsize,
               this->ovysize, dataTmp, this->ovxsize, this->ovysize,
               band->GetRasterDataType(), 0, 0);

The old python call was:

dataTmp = band.ReadAsArray(ovleft, ovtop,
    ovxsize, ovysize,
    dspRastXSize, dspRastYSize)

Thanks in advance

Gareth Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160511/17bcfe01/attachment-0001.html>

More information about the gdal-dev mailing list