[gdal-dev] Multi-threading GDALRasterBand::RasterIO() ?

[Simon Eves]

We are writing a raster importer, and finding that
GDALRasterBand::RasterIO() is unexpectedly slow for some GRIB2 files.

We have a file which is about 1800x1000 pixels, with 49 bands of type
DOUBLE. The file is about 47MB on disc.

Reading all the bands of a single scanline from this file takes about
1300ms, which is about 26ms per band, hence the entire file takes around 20
minutes to import. All the time seems to be spent in the RasterIO() call,
even though it's not doing any raster rescaling or data format conversion
(1:1 pixels, fetching as GDT_Float64).

So, I figured we'd try multi-threading it, but evidently the call is not
thread-safe. Here is just one of various stack traces it will throw.

libc.so.6!raise (Unknown Source:0)
libc.so.6!abort (Unknown Source:0)
libc.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0)
libgdal.so.28!GRIBRasterBand::UncacheData(GRIBRasterBand * const this)
(/build/scripts/gdal-3.2.2/frmts/grib/gribdataset.cpp:948)
libgdal.so.28!GRIBRasterBand::LoadData(GRIBRasterBand * const this)
(/build/scripts/gdal-3.2.2/frmts/grib/gribdataset.cpp:730)
libgdal.so.28!GRIBRasterBand::LoadData(GRIBRasterBand * const this)
(/build/scripts/gdal-3.2.2/frmts/grib/gribdataset.cpp:697)
libgdal.so.28!GRIBRasterBand::IReadBlock(GRIBRasterBand * const this, int
nBlockYOff, void * pImage)
(/build/scripts/gdal-3.2.2/frmts/grib/gribdataset.cpp:803)
libgdal.so.28!GDALRasterBand::GetLockedBlockRef(int bJustInitialize, int
nYBlockOff, int nXBlockOff, GDALRasterBand * const this)
(/build/scripts/gdal-3.2.2/gcore/gdal_priv.h:963)
libgdal.so.28!GDALRasterBand::GetLockedBlockRef(GDALRasterBand * const
this, int nXBlockOff, int nYBlockOff, int bJustInitialize)
(/build/scripts/gdal-3.2.2/gcore/gdalrasterband.cpp:1238)
libgdal.so.28!GDALRasterBand::IRasterIO(GDALRasterBand * const this,
GDALRWFlag eRWFlag, int nXOff, int nYOff, int nXSize, int nYSize, void *
pData, int nBufXSize, int nBufYSize, GDALDataType eBufType, GSpacing
nPixelSpace, GSpacing nLineSpace, GDALRasterIOExtraArg * psExtraArg)
(/build/scripts/gdal-3.2.2/gcore/rasterio.cpp:149)
libgdal.so.28!GDALRasterBand::RasterIO(GDALRasterBand * const this,
GDALRWFlag eRWFlag, int nXOff, int nYOff, int nXSize, int nYSize, void *
pData, int nBufXSize, int nBufYSize, GDALDataType eBufType, GSpacing
nPixelSpace, GSpacing nLineSpace, GDALRasterIOExtraArg * psExtraArg)
(/build/scripts/gdal-3.2.2/gcore/gdalrasterband.cpp:372)
import_export::Importer::<lambda(size_t, int)>::operator()(size_t, int)
const(const import_export::Importer::<lambda(size_t, int)> * const
__closure, const size_t thread_id, const int y)
(/home/simon.eves/work/omniscidb-internal/ImportExport/Importer.cpp:5721)
...

All of the parameters to the call are either constant or uncontended simple
variables, and obviously there is a unique data buffer (pData) per thread.

Is there anything we can do to make this work?

I was intending to look into the lower level block-based API, in the hope
that it will be faster, but have not yet done so.

This is all with a local static build of GDAL 3.2.2 on Ubuntu 20.04 with
GCC 9.

Yours,

Simon Eves

-- 
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.eves at omnisci.com | Cell:  +1 (415) 902-1996
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20211031/3c11f55c/attachment.html>