Summary
The v3.10.0 pre-publish benchmark gate detected a query-path regression on the native engine. fnDeps queries became ~52% slower at all depths. The publish was correctly blocked from npm by the regression guard (failed run).
Regression deltas (v3.10.0 vs v3.9.6, native engine, 25% threshold)
- fnDeps depth 1: 28.7ms → 43.7ms (+52%, +15ms absolute)
- fnDeps depth 3: 29.1ms → 44.1ms (+52%, +15ms absolute)
WASM engine was unaffected. fnImpact and diffImpact were within threshold.
Pattern
The +15ms absolute delta is identical for depth 1 and depth 3 — the slowdown is independent of traversal depth. This is the signature of a per-call setup cost added to the native query path, not a hot-loop slowdown.
Likely shared root cause with #1054
#1054 documents a flat ~2080ms overhead on native rebuilds. This issue shows a flat ~15ms overhead on native queries. Both are native-engine-only and both look like per-call initialization costs added to the JS wrapper. They are very likely the same underlying defect manifesting at different scales.
If fixing #1054 also clears this benchmark, close this as duplicate. Tracked separately because the regression guard reports them as distinct test failures and the user-visible impact (queries vs rebuilds) is different.
Historical context
The regression-guard test file already documents fnDeps native overhead from v3.9.0 (openRepo() always routing through native NAPI). That was fixed in v3.9.1+. The current regression is a new ~15ms overhead on top of the corrected v3.9.6 baseline, not a return of the old bug.
Reproduction
git checkout v3.10.0
npm install
npm run build
node --import ./scripts/ts-resolve-loader.js scripts/query-benchmark.ts --version 3.10.0
Compare `native.fnDeps.depth1Ms` and `native.fnDeps.depth3Ms` to the v3.9.6 baseline in `generated/benchmarks/QUERY-BENCHMARKS.md`.
Acceptance criteria
- Native fnDeps depth 1 back to <35ms (was 28.7ms in v3.9.6)
- Native fnDeps depth 3 back to <35ms (was 29.1ms in v3.9.6)
- `npm run test:regression-guard` passes against the v3.9.6 baseline
Summary
The v3.10.0 pre-publish benchmark gate detected a query-path regression on the native engine. fnDeps queries became ~52% slower at all depths. The publish was correctly blocked from npm by the regression guard (failed run).
Regression deltas (v3.10.0 vs v3.9.6, native engine, 25% threshold)
WASM engine was unaffected. fnImpact and diffImpact were within threshold.
Pattern
The +15ms absolute delta is identical for depth 1 and depth 3 — the slowdown is independent of traversal depth. This is the signature of a per-call setup cost added to the native query path, not a hot-loop slowdown.
Likely shared root cause with #1054
#1054 documents a flat ~2080ms overhead on native rebuilds. This issue shows a flat ~15ms overhead on native queries. Both are native-engine-only and both look like per-call initialization costs added to the JS wrapper. They are very likely the same underlying defect manifesting at different scales.
If fixing #1054 also clears this benchmark, close this as duplicate. Tracked separately because the regression guard reports them as distinct test failures and the user-visible impact (queries vs rebuilds) is different.
Historical context
The regression-guard test file already documents fnDeps native overhead from v3.9.0 (
openRepo()always routing through native NAPI). That was fixed in v3.9.1+. The current regression is a new ~15ms overhead on top of the corrected v3.9.6 baseline, not a return of the old bug.Reproduction
Compare `native.fnDeps.depth1Ms` and `native.fnDeps.depth3Ms` to the v3.9.6 baseline in `generated/benchmarks/QUERY-BENCHMARKS.md`.
Acceptance criteria