Skip to content

bench: scenario_bench — session-level typechecker cost/benefit (REPL/SDK/one-shot/write-heavy) - #88

Open
Felipe705x wants to merge 2 commits into
tc-perf/08-meet-memofrom
tc-perf/09-scenario-bench
Open

bench: scenario_bench — session-level typechecker cost/benefit (REPL/SDK/one-shot/write-heavy)#88
Felipe705x wants to merge 2 commits into
tc-perf/08-meet-memofrom
tc-perf/09-scenario-bench

Conversation

@Felipe705x

Copy link
Copy Markdown
Collaborator

Stacked on #87. The measurement layer the whole series was missing: sessions, not isolated calls.

Neither existing instrument models what users experience — the internal bench measures per-case pipeline cost (its question: net guardrail value), pattern_typecheck measures the checker in a hot loop (its question: component attribution, patterns-only by design for the Python comparison). This bin replays named session profiles end-to-end in two configs (tc-on = REPL behavior, tc-off = unchecked counterfactual), with fresh store+caches per session, AB/BA interleave against machine drift, an LLC-sized eviction sweep standing in for human think-time, and setup time + RSS as first-class columns — the amortization/memory ledger.

First results (LDBC SF0.1, 3 reps, idle):

profile question tc-on tc-off verdict
repl_explorer guardrail value where mistakes happen naturally 84–97 s, ~150 MiB 117–133 s, ~197 MiB ~30% of session saved
sdk_app (300 reqs) the TAX of leaving tc on 630 ms 630 ms ~10 µs/request — free
one_shot_reject_lazy cost-to-first-verdict 0.095 ms, 395 MiB 920 ms, 537 MiB ~10⁴× + 140 MiB
write_heavy DML invalidation asymmetry 8–10 ms 4.6–4.7 s ~500×

Bonus finding: the "runtime rejects bad queries in 11 µs" number from hot-loop measurements requires ~2.2 s of session setup (open + index warm) that the typechecker's verdict never needed — the runtime's fast rejection is exactly as regime-dependent as the typechecker's was before this series.

Documented limitations in the module doc: eviction sweep ≠ real seconds-long pauses; repl_explorer's drift/error knobs are synthetic (no organic traces exist yet) and meant to be swept.

🤖 Generated with Claude Code

Felipe705x and others added 2 commits July 24, 2026 02:47
…cking

"We cannot improve what we cannot measure": the internal bench measures
per-case pipeline cost and pattern_typecheck measures the checker in a
hot loop; neither models a SESSION — amortization horizon, shape
novelty, human think-time (hardware-cache eviction between queries),
error mix, DML interleaving. This bin replays named session profiles
end-to-end, tc-on vs tc-off, fresh store+caches per session, AB/BA
config interleave, an LLC-sized eviction sweep as think-time, and the
amortization/memory ledger (open/warm time, RSS) as first-class output.

Profiles and first results (LDBC SF0.1, 3 reps, idle machine):
- repl_explorer (typos/drift/DML — where mistakes happen naturally):
  tc-on 84–97 s vs tc-off 117–133 s per session (~30% saved) and
  ~50 MiB lower peak RSS; 6 mistakes rejected in microseconds.
- sdk_app (reviewed templates × 300 requests — errors impossible by
  construction; measures the TAX of leaving typechecking on):
  ~10 us/request; session totals statistically identical. Answer:
  it's free, leave it on.
- one_shot_reject_lazy (cost-to-first-verdict with the setup each
  path actually needs): tc-on 0.095 ms at 395 MiB vs tc-off 920 ms
  at 537 MiB — the runtime must build its ~140 MiB index to learn
  what the schema already knew.
- one_shot_reject_eager: the "runtime rejects in 11 us" number from
  hot-loop benches requires ~2.2 s of session setup the typechecker
  never needed; per-session the two verdicts cost the same order.
- write_heavy (DML→query cycles, lazy runtime): tc-on 8–10 ms vs
  tc-off 4.6–4.7 s (~500×) — each mutation invalidates the runtime's
  index (~0.9 s rebuild) while the typechecker's schema-side caches
  rebuild lazily in microseconds.

Documented limitations: think-time eviction cannot model frequency
scaling/predictor decay of real pauses; repl_explorer's drift/error
mix is synthetic (no organic usage traces exist yet) and its knobs
are meant to be swept.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The legacy `bench` case set is patterns-only by design — it mirrors the
Python reference checker, which supported only path patterns (right
shape, not the queries users type). New `full` category exercises
RETURN typing, ORDER BY (column and alias), aggregates, and the
multi-MATCH collapse path; the legacy set stays intact for its
comparison purpose.

Verdicts all correct; full queries typecheck at 3.4–13 µs on the LDBC
schema (1.1–4.1× parse cost).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant