Repository navigation
Calibrate ParseCostProbeSpec's median ceiling for shared CI runners - #270
Merged
Merged
Conversation
…CI runners The 1 ms ceiling was ~15x the worst median measured on Apple silicon; a loaded GitHub runner measures >20x that baseline, so the probe flunked runs whose diff never touched the parse (PRs #263/#266, both 1.35-1.42 ms at 32 KB). The ceiling is now 10 ms — ~7x the worst CI-observed median, still ~150x the local one — so a categorical regression fails everywhere and a slow runner passes. Closed Issue #269 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fupelaqu
marked this pull request as ready for review
September 2, 2026 14:38
This was referenced Sep 15, 2026
fupelaqu
added a commit
that referenced
this pull request
Sep 23, 2026
Asked for by the lead while reviewing #382: "We added since v0.24.0 a lot of treatments within SearchApi, how does it affect the performance? The SQL parsing and the rendering have been checked regularly, I wonder if the impacts of effective search have been ever measured properly." They had not. `ParseCostProbe` measures parsing, `EmissionCostProbe` measures rendering, and core's `ParseCostProbeSpec` measures RESPONSE parsing — nothing measured the work between "the statement is parsed" and "Elasticsearch is called", which is where 0.24.0 put most of its new per-request work: the relational-closure guard (22.1), uncorrelated WHERE-subquery phase one (22.2), temporal-literal normalisation (#276), the schema ATTACH (#306), and the post-resolution rules `Case.conditionsOf` (#384) and `NullIf.mismatchesOf` (#382). `ResolveCostProbe` reports, per statement: `parse` (the yardstick), the whole `resolve`, `attach`, `temporal`, `validate`, and `resolve x2`. 🔴 `resolve x2` is the number an un-LIMITed row query really pays: `search` resolves, then routes through `scrollRows` -> `ScrollApi.scroll`, which resolves AGAIN — stated in `resolveWithSchema`'s own comment and pinned by `SchemaAttachSpec`'s idempotence test. Quoting `resolve` alone understates that shape by 2x. First baseline (Apple silicon, 800 runs after 150 discarded): resolution is 0.4-5 % of the parse it follows — 0.6-8.4 us against a 69-356 us parse. Two things that looked expensive are not: `validateResolved` costs 0.1-0.9 us, so the second AST walk is a clarity finding and not a cost one, and the whole `update(Some(schema))` rebuild is 0.5-1.5 us even for a window or GROUP BY. The only stage that registers is `TemporalLiterals` at ~2.7 us, and only for a statement that carries a temporal WHERE literal.⚠️ It excludes `loadSchema` (cached — an IO miss is a different order) and the Elasticsearch round-trip, and it is an ABSOLUTE measurement, not an attribution against a 0.23.x control. No assertion, a `main` only — #269/#270 spent a round on a timing assertion that flunked unrelated PRs on loaded CI runners. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #269
What
One-file test calibration:
MedianCeilingNanos1 ms → 10 ms inParseCostProbeSpec, scaladoc updated with the CI data points, test name no longer hard-codes the number.Why
The probe (added by #238) measures the raw json4s-jackson parse of the scroll request body and asserted the pathological 31.7 KB body's median stays under 1 ms — '~15× the worst measured median', but that median was measured on Apple silicon (0.067 ms). Loaded shared GitHub runners measure 1.35–1.42 ms (observed 2026-09-02 on the PR #263 and #266
testjobs — identical failure, all 820 other tests green, while #264 passed the same suite the same day). Nothing in a PR's diff can affect the number, so a red run says nothing about the PR.The new ceiling is ~7× the worst CI-observed median and still ~150× the local one: a categorical regression (parser swap, accidental re-parse loop) blows past it on any machine; a slow runner does not.
Verification
core/testOnly *ParseCostProbeSpecgreen locally (p50 0.07 ms at 32 KB — matches the original baseline).++ 2.12.20 core/Test/compilegreen (0 errors);scalafmtAllapplied.🤖 Generated with Claude Code