Reason or Problem
The focal and proximity test suites take about 58 seconds locally. A few specific patterns dominate the runtime:
test_apply_rejects_oversize_kernel_1284, test_focal_stats_rejects_oversize_kernel_1284, and test_hotspots_rejects_oversize_kernel_1284 each allocate a (50001, 50001) float32 kernel just to trip the memory-guard MemoryError. The np.ones call alone takes about 5 seconds and pins 10 GB of RAM, even though the guard only does shape arithmetic against _available_memory_bytes().test_focal.py builds data_random_sparse and data_gaussian at import time. Neither is referenced anywhere in the file.test_mean_transfer_function_dask_cpu and test_mean_transfer_function_dask_gpu chunk a 100x100 array with chunks=(3, 3), producing a 1156-chunk dask graph. The dask path runs the same with a handful of chunks.- Several
pytest.mark.parametrize sweeps over (boundary, size, chunks) repeat the same cross-backend assertion across redundant combinations.
Proposal
Reduce the test wall-clock without losing coverage:
- Patch
xrspatial.focal._available_memory_bytes to return a tiny value and use a small kernel in the three oversize-kernel tests. The guard still fires and the test still asserts the same behavior, but we skip the 10 GB allocation.
- Delete the unused module-level
data_random_sparse and data_gaussian.
- Use larger dask chunks in the mean-transfer-function dask tests.
- Trim the
(size, chunks) matrix in the boundary parity tests to keep small, medium, and chunk-equals-array cases without duplicating mid-range combinations.
Value
Faster feedback for anyone running or modifying tests in xrspatial.focal or xrspatial.proximity, and shorter CI for PRs that touch either module.
Drawbacks
Lower-priority shape combinations get dropped from the parametrize matrix. If a regression hides specifically in one of those combinations, it could slip through.
Reason or Problem
The focal and proximity test suites take about 58 seconds locally. A few specific patterns dominate the runtime:
test_apply_rejects_oversize_kernel_1284,test_focal_stats_rejects_oversize_kernel_1284, andtest_hotspots_rejects_oversize_kernel_1284each allocate a(50001, 50001)float32 kernel just to trip the memory-guardMemoryError. Thenp.onescall alone takes about 5 seconds and pins 10 GB of RAM, even though the guard only does shape arithmetic against_available_memory_bytes().test_focal.pybuildsdata_random_sparseanddata_gaussianat import time. Neither is referenced anywhere in the file.test_mean_transfer_function_dask_cpuandtest_mean_transfer_function_dask_gpuchunk a 100x100 array withchunks=(3, 3), producing a 1156-chunk dask graph. The dask path runs the same with a handful of chunks.pytest.mark.parametrizesweeps over(boundary, size, chunks)repeat the same cross-backend assertion across redundant combinations.Proposal
Reduce the test wall-clock without losing coverage:
xrspatial.focal._available_memory_bytesto return a tiny value and use a small kernel in the three oversize-kernel tests. The guard still fires and the test still asserts the same behavior, but we skip the 10 GB allocation.data_random_sparseanddata_gaussian.(size, chunks)matrix in the boundary parity tests to keep small, medium, and chunk-equals-array cases without duplicating mid-range combinations.Value
Faster feedback for anyone running or modifying tests in
xrspatial.focalorxrspatial.proximity, and shorter CI for PRs that touch either module.Drawbacks
Lower-priority shape combinations get dropped from the parametrize matrix. If a regression hides specifically in one of those combinations, it could slip through.