Describe the bug
xrspatial/tests/test_polygonize.py::TestSimplifyHelpers::test_visvalingam_whyatt_scales_subquadratic fails intermittently on CI. It times _visvalingam_whyatt at input sizes 2000 -> 32000 and asserts that each doubling stays under a 3.0x wall-clock ratio (to catch O(n^2) regressions). On a loaded or shared runner a single slow timing sample pushes the ratio over the threshold.
Observed across four consecutive runs on PR #2874 (a viewshed-only change that does not touch polygonize), each with a different ratio:
- ubuntu-latest 3.14: ratio 3.46x
- windows-latest 3.14: ratio 3.26x
- windows-latest 3.14: ratio 4.98x
The matrix uses fail-fast, so each failure also cancels the sibling macos/windows jobs, which makes the whole pytest workflow red.
Why it flakes
The test asserts an asymptotic-complexity property (O(n log n)) using a hard wall-clock ratio. Timing on a contended CI runner is noisy, especially for the small 2000-element baseline. GC pauses, scheduler preemption, and turbo-clock variance all move the ratio. A complexity check expressed as a single absolute wall-clock threshold is inherently flaky in CI.
Suggested fix (for a separate PR)
A few options, in rough order of robustness:
- Compare against a fitted slope on a log-log plot over all five sizes instead of pairwise consecutive ratios, and assert the exponent is well under 2.
- Take the minimum (or median) of several timed repeats per size rather than a single mean, to reject outliers.
- Loosen the per-step threshold (it already allows ~3x against an O(n^2) baseline of ~4x; the margin is thin under noise) or skip the timing assertion under known-noisy CI via a marker.
Notes
This is unrelated to PR #2874; surfacing it here so the timing flake gets its own fix rather than being absorbed into an unrelated change. The test was last modified in #2817.
Describe the bug
xrspatial/tests/test_polygonize.py::TestSimplifyHelpers::test_visvalingam_whyatt_scales_subquadraticfails intermittently on CI. It times_visvalingam_whyattat input sizes 2000 -> 32000 and asserts that each doubling stays under a 3.0x wall-clock ratio (to catch O(n^2) regressions). On a loaded or shared runner a single slow timing sample pushes the ratio over the threshold.Observed across four consecutive runs on PR #2874 (a viewshed-only change that does not touch polygonize), each with a different ratio:
The matrix uses fail-fast, so each failure also cancels the sibling macos/windows jobs, which makes the whole pytest workflow red.
Why it flakes
The test asserts an asymptotic-complexity property (O(n log n)) using a hard wall-clock ratio. Timing on a contended CI runner is noisy, especially for the small 2000-element baseline. GC pauses, scheduler preemption, and turbo-clock variance all move the ratio. A complexity check expressed as a single absolute wall-clock threshold is inherently flaky in CI.
Suggested fix (for a separate PR)
A few options, in rough order of robustness:
Notes
This is unrelated to PR #2874; surfacing it here so the timing flake gets its own fix rather than being absorbed into an unrelated change. The test was last modified in #2817.