[gdal-dev] How to improve image access performance using libGDAL1.5?

[W. A. Harvey]

I have a few questions about how I can improve performance when using the
GDAL image libraries.

Background: I have a tiled image format that was developed back when the
earth was cooling. I also have a large number of applications that use this
format, ranging from basic computer vision tasks to display of
large-scale textures for visualization applications. The format has an
API that supports efficient pixel, row/col, and block access to byte,
multi-byte and floating-point image data. I'm attempting to re-implement
this API using calls to GDAL so that, with just a recompile/re-link,
the existing applications can ingest and operate on all the image formats
supported by GDAL.

After writing some of the primary API functions, I compiled several of
the simpler applications so that I could test both the correctness and
the performance of my implementation. The performance numbers I've
collected so far show that the GDAL-based version is 3-4 times slower
when reading/writing "blocks" (rows, cols, blocks) of data, and about
100 times slower when reading/writing pixel data. These numbers are
about the same regardless of the type of input image -- jpeg, tiff, gif,
nitf -- or image size.

I need to improve the pixel-based access performance to make this
implementation viable, though I'd certainly like to improve the
performance of the block-based access, too. I've tried several different
modifications to improve the speed, including:
 a. Increasing the cache size via GDALSetCacheMax(), including
   increasing the size to be larger than the size of the test image.
 b. Compiling the libraries with optimization;
 c. Instead of using RasterIO(), implementing pixel access using
   "blocks" obtained with GetLockedBlockRef() and sub-indexed using
   SRCVAL().
Profiling the applications shows that they're spending the most time
(>80%) in the primary GDAL access routines: GDALRasterBand::RasterIO()
and GDALRasterBand::GetLockedBlockRef(). This is expected because the
test applications are relatively simple -- inverting an image,
flipping/rotating an image, sub-sampling an image, etc.

Environment: WindowsXP Pro SP2, Visual Studio 6 (I know, I know ...), Dual
3.4GHz Xeon processors, 2GB memory, libGDAL1.5.1.

My questions: Can anyone suggest other specific things I can do to try
to improve the performance of the GDAL-based library?  Should I consider
implementing my own caching mechanism that would sit between my API
functions and the GDAL calls? Though I thought that that was the purpose
of GDAL's internal caching mechanism. If there are other ways to "tune"
the cache, I overlooked them in the GDAL documentation and wiki.

It appears to me that most people use GDAL to convert their data between
various image formats, but I'm not aware of people using it as a basis
for their image access APIs. Am I "abusing" GDAL by using it this way?

Thanks in advance for your thoughts/suggestions. -Wilson