<div dir="ltr"><div><span style="font-family:Arial">Laurentiu,<br><br>Bumping </span><a href="https://gdal.org/en/stable/user/configoptions.html#config-GDAL_MAX_DATASET_POOL_SIZE" target="_blank" style="font-family:Arial">GDAL_MAX_DATASET_POOL_SIZE</a><span style="font-family:Arial"> did not make any difference for me. My source rasters are of different block sizes but they are relatively small. As you have noted, the drastic performance difference with or without Pixel Func points to something else not tiling. I agree.<br><br><br></span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px 0px 10px;font-size:12px;line-height:14px"><font style="color:rgb(33,33,33)" face="arial, helvetica, sans-serif"><span style="font-weight:bold">Abdul</span></font></p></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 14, 2025 at 4:20 AM Rahkonen Jukka <<a href="mailto:jukka.rahkonen@maanmittauslaitos.fi" target="_blank">jukka.rahkonen@maanmittauslaitos.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Some previous discussion about the same thing in <a href="https://gis.stackexchange.com/questions/491309/performent-way-of-merging-multiple-rasters-into-a-single-cog-gtiff-with-gdal-w" rel="noreferrer" target="_blank">https://gis.stackexchange.com/questions/491309/performent-way-of-merging-multiple-rasters-into-a-single-cog-gtiff-with-gdal-w</a>?<br>
<br>
With untiled images it is not a surprise that small -projwin does not have a great effect. But with 1000x1000 pixels sized images and the default tile size 256x256 splittin images internally into four would probably not make much difference anyway.<br>
<br>
Processing time and memory usage seems to grow linearly when the number of files in the VRT is increasing. Maybe this is good news.<br>
<br>
-Jukka Rahkonen-<br>
<br>
________________________________________<br>
Lähettäjä: gdal-dev käyttäjän Abdul Raheem Siddiqui via gdal-dev puolesta<br>
Lähetetty: Maanantai 14. huhtikuuta 2025 7.52<br>
Vastaanottaja: <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
Aihe: [gdal-dev] Performance Issue with VRT Pixel Function and Large Number of Source Rasters<br>
<br>
Dear GDAL Community,I am encountering a performance issue when using a VRT consisting of a large number of source rasters and built-in C++ pixel function ("max"). I would appreciate any guidance on whether some GDAL config option can improve this, or I am doing something wrong, or this is a potential optimization opportunity.I have A VRT file referencing ~750 individual rasters (Byte data type, avg size ~1000x1000 pixels, untiled, and same CRS for all source rasters). The VRT uses the built-in “max” pixel function.Running gdal_translate to convert the VRT to GTiff takes ~1.5 hours and consumes ~4GB RAM.gdal_translate -of GTiff merged.vrt OUTPUT.tifWhen tripling the number of source rasters (to ~2250) by duplicating entries in the VRT, processing time increases to ~4.5 hours, with RAM usage rising to ~11.5GB.gdal_translate -of GTiff merged_3x.vrt OUTPUT.tifExtracting a small subset of the VRT via -projwin does not improve performance (still slow, ~14GB RAM used).gdal_translate -projwin -146955.241 797044.4497 -138766.1444 789656.0648 -of GTiff merged_3x.vrt OUTPUT.tifRemoving the pixel function makes processing instantaneous, even with 2250 rasters.Performance is unaffected by --config GDAL_CACHEMAX or -co NUM_THREADS=ALL_CPUS.The issue persists across other datasets that I have. In fact, it gets really worse when source rasters are relatively larger or of Float32 data type.Gdalinfo on one of the source rasters: <a href="https://pastebin.com/gjHDA2WdData" rel="noreferrer" target="_blank">https://pastebin.com/gjHDA2WdData</a>: <a href="https://drive.google.com/file/d/1LGlzGGZvkPyXvKKgkPVzQGbBw55p5dRd/view?System" rel="noreferrer" target="_blank">https://drive.google.com/file/d/1LGlzGGZvkPyXvKKgkPVzQGbBw55p5dRd/view?System</a>: Windows, 8 CPUs, 32GB RAM (GDAL 3.9.2 via OSGeo4W).Thank you for your time and insights. Please reply if you are aware of how performance can be improved.Regards,Abdul Siddiqui, PEabdul.siddiqui@ertcorp.comERT  | Earth Resources Technology, Inc.14401 Sweitzer Ln. Ste 300Laurel, MD 20707<a href="https://www.ertcorp.com" rel="noreferrer" target="_blank">https://www.ertcorp.com</a></blockquote></div>