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)
Change History (2)
by , 17 years ago
Attachment: | gdal_svn_trunk_dted_cache_all.patch added |
---|
comment:1 by , 16 years ago
Milestone: | → 1.6.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Patch commited in trunk in r14610. Config option renamed to GDAL_DTED_SINGLE_BLOCK. Test updated in r14611