OGRCoordinateTransformation / gdalwarp performance improvements

[rouault]

Series of performance enhancements to fix the performance regression of gdalwarp in the use case of #3470.

With GDAL 2.4 / PROJ 5.2 : ~ 80 ms
Before with GDAL 3.2 / PROJ 8: ~ 280 ms
With this PR + #3587 + OSGeo/PROJ#2583: ~ 105 ms

[rouault]

Detail revealed by instrumentation: PROJ 8 is actually faster to do UTM coordinate transformations than PROJ 5.2. 2 ms v 5 ms for that use case :-) (excluding the 10 ms to compute the initial transformation pipeline)
And if removing the -ts 1024 1024 to generate a 10907 x 12619 output, PROJ 8 spends 82 ms in coordinate transformation, vs 144 ms for PROJ 5.2. So overall, those enhancements mostly help for reprojection of small rasters.

[vincentsarago]

@rouault it looks great 🥳

I'm not sure to fully understand all the changes but looking at https://github.com/OSGeo/gdal/pull/3591/files#diff-a0bdcb93fd5f7a249b6c04945d04192d1083e75a07e58015f8a168091b787326R2500 does it means that GDAL will Cache the transformation from a CRS to another CRS? if yes, is it cache in the global gdal cache ? when does it get cleared ?

🙏

[rouault]

does it means that GDAL will Cache the transformation from a CRS to another CRS? if yes, is it cache in the global gdal cache ? when does it get cleared ?

Yes, but the cache has a limited working for now, that works fine for gdalwarp single-threaded use case. Basically when a coordinate transformation object is about to be destroyed, instead of being destroyed, it is put in a memory cache. When later, the same coordinate transformation would be re-instanciated, the cache is looked up first. This helps in gdalwarp downsampling case since we do a first pixel-to-pixel transformer on the full resolution dataset, and then a later one on the appropriate source overview. Both use the same CRS of course, so the cache is triggered.
The cache size is the default one of the generic lru11:Cache class, which is 64 objects. Older entries get evicted automatically when the cache saturates. This is independent from the GDAL block cache. The size of this coordinate transformation cache should remain very modest (1 MB or so likely)