Opened 17 years ago

Closed 16 years ago

#1909 closed enhancement (fixed)

[PATCH] Improve DTED read performance

Reported by: Even Rouault Owned by: warmerdam
Priority: normal Milestone: 1.6.0
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: DTED
Cc:

Description

I've tried to figure out how to improve DTED read performance. Currently DTED raster band reports 1 x nRasterYSize blocks, like the actual data organization within DTED files. However most processing algorithms usually process line by line. When we process a DTED file, it means that we need to get one different block for each pixel. For a DTED 2 file, it means more than 10 million block requests. Luckily there is a cache block in GDAL, but it gives it a lot of work.

The patch attached is not particularly smart, but leads to significant performance improvements (processing time divided by 2.5). It just reports one single block for the whole DTED file. As this is certainly not appropriate for all uses, it is only enabled when DTED_CACHE_ALL environment variable is ON.

I'm wondering if there are not smarter strategies that would guess the use of the data we are making and would adapt the block geometry dynamically, but I don't see how to do that in GDAL architecture.

Attachments (1)

gdal_svn_trunk_dted_cache_all.patch (2.3 KB ) - added by Even Rouault 17 years ago.

Download all attachments as: .zip

Change History (2)

by Even Rouault, 17 years ago

comment:1 by Even Rouault, 16 years ago

Milestone: 1.6.0
Resolution: fixed
Status: newclosed

Patch commited in trunk in r14610. Config option renamed to GDAL_DTED_SINGLE_BLOCK. Test updated in r14611

Note: See TracTickets for help on using tickets.