On Aug 22, 2009, at 4:51 AM, Hermann Peifer wrote:
Just to repeat my earlier observations: over the last days, I tried with all kinds of -wm and GDAL_CACHEMAX settings, and also added the options TILED=YES and SKIP_NOSOURCE=YES. I haven't documented the performance changes systematically, but my overall impression was that the changes were rather small. I also tried -multi on my dual processor machine, but I ended up with a fatal error.
In January 2009, working with GDAL version 1.6.0, I did some testing and documenting of the effect of GDAL_CACHEMAX. Using as input an uncompressed GeoTif 15,000 x 15,000 x 3 = 675 MB, organized into 1024 x 1024 tiles, I found that using gdal_translate to convert this GeoTif to a GeoJP2 with the default --config GDAL_CACHEMAX 40 took 10473 sec (= 175 minutes), but increasing GDAL_CACHEMAX by only 12.5% to --config GDAL_CACHEMAX 45 the processing took only 166 sec (= 2.7 minutes), which is 63 times faster! Further tests showed that increasing --config GDAL_CACHEMAX to values greater than 45 (up to 1800) did not effect processing time. Greg
GDAL 1.6.0, released 2008/12/04 Input GeoTif 15,000 x 15,000 x 3 = 675 MB gdal_translate -of JP2KAK -co QUALITY=10 --config GDAL_CACHEMAX 0040 10473.14 sec 0041 10326.75 sec 0042 10492.85 sec 0043 7081.57 sec 0044 3503.33 sec 0045 166.23 sec 0050 166.31 sec 0055 165.89 sec 0060 165.78 sec 0080 165.48 sec 0100 166.53 sec 0125 165.59 sec 0150 165.72 sec 0200 165.65 sec 0250 166.58 sec 0300 166.13 sec 0350 166.59 sec 0400 166.06 sec 0600 166.00 sec 0800 165.10 sec 1000 165.25 sec 1200 165.94 sec 1400 165.43 sec 1600 165.56 sec 1800 166.31 sec
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
