Ticket #2373 (closed defect: invalid)

Opened 2 months ago

Last modified 2 months ago

Significant Slowdown in RasterIO moving from GDAL 1.4.2 to 1.5.0 - is it just me?

Reported by: cmichaelis Assigned to: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: major Keywords:
Cc:

Description

Hi there,

I've updated our code to compile against GDAL 1.5.0 (statically linked) from previously compiling against 1.4.2 (also statically linked), and am seeing a pretty major slowdown using repeated AdviseRead? and RasterIO operations against TIFF files (e.g., http://svn.mapwindow.org/svnroot/SampleData/TIFF%20and%20GeoTiff/NLCD/maryland.nlcd.tif.gz).

Our software runs on Windows, FWIW - MapWindow? GIS. In both instances, libtiff 3.7.3 is used in nmake.opt.

Has anyone else out there seen behavior like this -- am I doing something wrong? I'm leaning toward it being me, but thought I'd report what I'm seeing anyway.

Cheers, --Chris

Change History

05/15/08 14:04:54 changed by rouault

I'm very surprised that you see slowdown when using AdviseRead? with GeoTIFF, because as far as I've looked in the code, the AdviseRead? method has never been implemented in the GTIFF driver... And as the default implementation is a no-operation, the use of AdviseRead? is and alwasy been a no-op for GeoTIFF.

For the RasterIO operation, could you provide a simple C or Python file with some RasterIO function calls with numeric values on your sample file and give the times they're running with GDAL 1.4.2 and 1.5.0 so that we could reproduce it ?

05/15/08 14:08:50 changed by cmichaelis

Certainly - I'll put together some test cases. It might be interesting to try on Linux too... I'll post a link to a project here shortly (possibly today, most likely tomorrow).

Thanks, --Chris

05/18/08 04:47:23 changed by cmichaelis

  • status changed from new to closed.
  • resolution set to invalid.

Very strange - when I alternate between GDAL versions, our own software slows down in the newer one. But, when I try to extract out the functionality, 1.5.0 is 3 seconds faster than 1.4.2. I can't seem to duplicate the slowdown except in this one routine... so it's got to be something odd going on in our side.

I'll close this ticket as I'm reasonably sure the problem is ours.

Thanks, --Chris

05/18/08 11:37:58 changed by warmerdam

Chris,

I'm not sure how you are calling GDAL or how you tried to extract the functionality, so it is hard to comment. I will note that gdal_translate *to* geotiff format now uses a chunking approach that may make it substantial faster than it was. Generally speaking GDAL can give odd performance depending on the cache memory available, IO strategy and the driver in use.

If you can isolate a particular case that has slowed down substantially I'd be interested in hearing more.