<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Matt,</p>
<p>I see that in the -multi mode, the I/O threads waits for a
maximum of 10 minutes for the computation thread to have finished.
And you likely hit that limit because of the large value of -wm
you set. There's no reason we max at 10 minutes however. Please
find a but about that, including my analysis.</p>
<p>For better speed, I'd suggest you add --config GDAL_NUM_THREADS
ALL_CPUS (or a given number of threads). The -multi switch only
does one thread for I/O and one thread for computation. By adding
--config GDAL_NUM_THREADS xxx you'll also multi-thread the
computation part. The gain of -multi alone is generally
neglectable. We should probably make -multi turn on --config
GDAL_NUM_THREADS ALL_CPUS as well.</p>
<p>I also see that the mode resampling spend an awful lot of time on
line "memset(panVals, 0, nBins*sizeof(int));" where nBins=65536 on
Int16 data, and that for each output pixel. We could probably do
something much less expensive for most cases. Please file a
separate enhancement ticket about that particular case.<br>
</p>
<p>Even</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 31/03/2021 à 18:46,
<a class="moz-txt-link-abbreviated" href="mailto:Matt.Wilkie@yukon.ca">Matt.Wilkie@yukon.ca</a> a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:9cf803e5a2b5441d901f411882178007@app-exch2.gov.yk.ca"><span
style="font-size:10.0pt;font-family:Consolas;color:#1F497D;mso-fareast-language:EN-US">gdalwarp
--config GDAL_CACHEMAX 4096 -wm 512 -multi -co TILED=YES -co
COMPRESS=ZSTD -t_srs EPSG:3579 -r mode -co predictor=2
tri_mergedDEM_clipped_16bit.tif
tri_mergedDEM_clipped_16bit_ytalb-rs-mode.tif </span></blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>