performance impact of GDAL3.2 / PROJ7.1

[vincentsarago]

in cogeotiff/rio-tiler#346 we are noticing some performance issues when using the latest rasterio wheels (built with GDAL3.2 and PROJ7.1). When trying to set PROJ_NETWORK=OFF I couldn't see any change locally.

For now I would advise to use rasterio==1.1.8 (installed from wheels) or to use GDAL 2.4.

cc @kylebarron @geospatial-jeff

[vincentsarago]

👋 I'm still working on this.

For now we have decided to pin rasterio==1.1.8 in the docker images #242

The problem doesn't come from rasterio but from GDAL 3.2 or more from PROJ 7.

From what I can see, the performance is worse, only when we need to do reprojection ... which is why I think this comes from PROJ.

Notes:

• PROJ_NETWORK=OFF (so we make sure we don't call network)
• Tested env:
  • debian: tiangolo/uvicorn-gunicorn:python3.8 using rasterio wheels (1.2.0 that comes with GDAL 3.2 and PROJ 7)
  • centos: lambgeo/lambda-gdal:3.2-python3.8 using Rasterio sources

Bench

To replicate the tiling process, we can use gdalwarp directly 👇

Files

• https://rio-tiler-dev.s3.amazonaws.com/data/m_3209542_se_15_060_20181115_20190222.tif
• https://rio-tiler-dev.s3.amazonaws.com/data/m_3209542_se_15_060_20181115_20190222_3857.tif

tile: 13-1916-3319
bounds: -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245

GDAL config:

• GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR
• GDAL_INGESTED_BYTES_AT_OPEN=40000

CENTOS (lambgeo/lambda-gdal:3.2-python3.8)

# File in epsg:26915
$ time gdalwarp m_3209542_se_15_060_20181115_20190222.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m0.196s
user    0m0.158s
sys     0m0.037s

# File in epsg:3857 (so no reprojection needed)
$ time gdalwarp m_3209542_se_15_060_20181115_20190222_3857.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222_3857.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m0.054s
user    0m0.040s
sys     0m0.013s

CENTOS (lambgeo/lambda-gdal:2.4-python3.8)

# File in epsg:26915
$ time gdalwarp m_3209542_se_15_060_20181115_20190222.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.

real    0m0.042s
user    0m0.026s
sys     0m0.016s

# File in epsg:3857 (so no reprojection needed)
$ time gdalwarp m_3209542_se_15_060_20181115_20190222_3857.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222_3857.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.

real    0m0.054s
user    0m0.022s
sys     0m0.015s

ALPINE (osgeo/gdal:alpine-ultrasmall-latest)

$ time gdalwarp m_3209542_se_15_060_20181115_20190222.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m 0.51s
user    0m 0.49s
sys     0m 0.01s

$ time gdalwarp m_3209542_se_15_060_20181115_20190222_3857.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222_3857.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m 0.07s
user    0m 0.05s
sys     0m 0.01s

Ubuntu (osgeo/gdal:ubuntu-small-3.2.1)

$ time gdalwarp m_3209542_se_15_060_20181115_20190222.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m0.167s
user    0m0.144s
sys     0m0.022s


$ time gdalwarp m_3209542_se_15_060_20181115_20190222_3857.tif out.tif -overwrite -te -10664494.18634779 3796168.572754994 -10659602.216537539 3801060.542565245 -t_srs EPSG:3857 -ts 256 256
Creating output file that is 256P x 256L.
Processing m_3209542_se_15_060_20181115_20190222_3857.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
real    0m0.060s
user    0m0.047s
sys     0m0.013s

refs:

• Build PROJ without sqlite dependencies OSGeo/PROJ#1552
• GDAL 3 performance issue lambgeo/docker-lambda#2
• install newer sqlite version RemotePixel/amazonlinux#17
• https://github.com/OSGeo/gdal/blob/0941b0f7aaa5bff5fd12a6fed03d4e385c4dcae4/gdal/doc/source/drivers/vector/sqlite.rst#performance-hints
• Poor performance of construction of CoordinateTransformation in 3.0. OSGeo/gdal#1662 (comment)

[vincentsarago]

https://cogeotiff.github.io/rio-tiler/#gdal30-proj60-performances-issue