Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#2373 closed defect (invalid)

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

Reported by: cmichaelis Owned by: 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 (4)

comment:1 by Even Rouault, 16 years ago

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 ?

comment:2 by cmichaelis, 16 years ago

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

comment:3 by cmichaelis, 16 years ago

Resolution: invalid
Status: newclosed

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

comment:4 by warmerdam, 16 years ago

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.

Note: See TracTickets for help on using tickets.