Describe the bug
The parallel tile decode path in xrspatial/geotiff/_reader.py (around line 1091) is gated by:
use_parallel = (n_tiles > 1 and tile_pixels > 64 * 1024)
For the default tile_size=256, tile_pixels = 256 * 256 = 65536, which is exactly 64 * 1024. The strict > fails by one, so the sequential path runs even with 16+ tiles. The parallel decode only fires for tile_size > 256, but 256 is the default that most real GeoTIFFs ship with. The gate is closed on the most common case.
Expected behavior
The threshold should be >= so the default tile size engages parallel decode. The comment next to the line says the threshold is meant to "avoid pool overhead on small 64x64 / 128x128 tile reads" - 256x256 should clear it, not land on it.
Fix
One-character change:
use_parallel = (n_tiles > 1 and tile_pixels >= 64 * 1024)
Additional context
Found during an efficiency audit pass over the geotiff module on 2026-05-09.
Describe the bug
The parallel tile decode path in
xrspatial/geotiff/_reader.py(around line 1091) is gated by:For the default
tile_size=256,tile_pixels = 256 * 256 = 65536, which is exactly64 * 1024. The strict>fails by one, so the sequential path runs even with 16+ tiles. The parallel decode only fires fortile_size > 256, but 256 is the default that most real GeoTIFFs ship with. The gate is closed on the most common case.Expected behavior
The threshold should be
>=so the default tile size engages parallel decode. The comment next to the line says the threshold is meant to "avoid pool overhead on small 64x64 / 128x128 tile reads" - 256x256 should clear it, not land on it.Fix
One-character change:
Additional context
Found during an efficiency audit pass over the geotiff module on 2026-05-09.