Repository navigation
Benchmark regression: negation (v3) #669
Description
Bencher flagged these benchmarks in the nightly run (negation, v3) on two runs in a row:
negation/not_rule_body/10knegation/not_rule_body/1k
Branch: v3
Run: https://github.com/project-minigraf/minigraf/actions/runs/39472884024
Previous run: https://github.com/project-minigraf/minigraf/actions/runs/39312292697
Please review the Bencher dashboard to confirm the regression.
Activity
adityamukho commentedon Oct 21, 2026
Confirmed real, and already resolved on the current
v3tip.Nightly numbers (v3)
b21708a3d87dfff884ac8457Cause. Bisected with the same rule query and fixture (1k entities, 10% blocked): the step is
491049e0(#624, "compare imported values by join equality on every executor path", #546): 17.5 → 206 ms at 1k. Since thenStratifiedEvaluatormatches each candidate row'snotbody withmatch_patterns_seededfrom a one-row seed. That takesjoin_with_pattern's hash-join path, which scans every fact and builds bindings for every:blockedfact once per outer row. The old literal substitution matched only 0–1 facts per row.mainhas noseeded_body_rows, so this was v3-only.Resolution. #670 (#548, Recursive operator) runs rule queries on the streaming engine, which bypasses this path. Local timings (laptop, noisy):
2bef68a7(feat(engine): rule queries on the streaming engine (#548 PR 2) #670): 7.5 ms at 1kdf7282f1: 2.5 ms at 1k, 27 ms at 10k, well below the pre-regression baselineRemaining. The executor/evaluator path still runs negation bodies per row this way (
StratifiedEvaluator,evaluate_not_join,not_body_matches). It only runs when the engine can't plan a query, and under the test oracle. #551 removes it.Closing; the next v3 nightly should confirm the numbers.