Benchmark regression: checkpoint (main)

Bencher flagged these benchmarks in the nightly run (checkpoint, main) on two runs in a row:

Branch: main
Run: https://github.com/project-minigraf/minigraf/actions/runs/38526373427
Previous run: https://github.com/project-minigraf/minigraf/actions/runs/38373154795

Please review the Bencher dashboard to confirm the regression.

Not a regression. Two things are stacked here:

The fix(db): stale WAL removed by checkpoint; usize::MAX threshold skips close-time save (#457, #476, v2.x backport) #540 step (same as Benchmark regression: open (main) #561/Benchmark regression: checkpoint (main) #562/Benchmark regression: open (main) #573/Benchmark regression: checkpoint (main) #574): checkpoint/100k went from ~4.5 ms to ~2.2 s and checkpoint/1m from ~41 ms to ~25 s at a861e55 (2026-10-11). Before fix(db): stale WAL removed by checkpoint; usize::MAX threshold skips close-time save (#457, #476, v2.x backport) #540 these fixtures were no-ops. The 30-run window from ci(bench): compare each run with the last 30 runs, not all history #568 is still absorbing that step.
A slow runner on 2026-10-14: 100k went 2.2 s → 4.35 s and 1m went 25.1 s → 40.5 s between d604cc4 and d3e5ad1. The only change to src/benches/Cargo.* between those commits is the 2.0.5 → 2.0.6 version bump (fuzz(datalog_eval): skip inputs whose patterns join to a cross product (#575) #577 is fuzz-only; docs(claude): merge main into v3 once, at the v3.0.0 cut #583 is docs). Unrelated benches slowed by the same factor in the same run: query/point_entity/1k 1.75×, query/regex_filter/1k 1.8×, temporal_metadata/tx_time/1k 1.74×, aggregation/count_scale/1k 1.86×. The I/O-heavy checkpoint benches took the worst of it (up to 3× for checkpoint/after_1_fact/100k).

If tomorrow's main run stays near 4 s / 40 s, I'll reopen this.

Navigation Menu