Repository navigation
ci(cli): judge block-scoped benchmark timings by per-block spread - #7433
Conversation
Block-scoped workloads now run in blocks of two launches, so each build gets five stack sessions at ten runs. Launches record their block index, and the timing verdict needs a strict majority of paired blocks to move the same way past the noise floor before it reads slower or faster. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CLI benchmark (Lightweight Commands): no changes foundCommit
API calls: unchanged for all 7 commands. Binary size: 134.0 MB, unchanged. Details: timing ranges, API calls per command, slowest phasesTiming ranges
API calls per command
Slowest phasesNo command moved beyond noise, so there are no phase deltas. Comment Previous runs
|
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews were available. Confirmed Claude’s test-coverage nit; no runtime defects identified. Corrected the finding’s line numbers to match the checked-out code.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| ⚪ NIT | apps/cli/scripts/bench-report.unit.test.ts:220 |
test-coverage |
claude | The mixed-sign blocks test passes even if the block agreement check is bypassed. It therefore does not verify that disagreement suppresses a verdict the fallback range check would flag. |
Stats
Claude findings: 1 · Codex findings: 0 · Confirmed: 1 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
|
/bench full |
CLI benchmark (Integration Heavy Commands): 1 thing to checkCommit
API calls: none, before or after, for all 27 commands. Container operations: unchanged for all 17 commands. Binary size: 134.0 MB, unchanged. Details: timing ranges, API calls per command, container operations, slowest phasesTiming ranges
API calls per command
Container operations per command
Slowest phases
Comment |
…timing verdict Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
/bench full |
avallete
left a comment
There was a problem hiding this comment.
LGTM, only a few questions.
Also, I wonder if instead of a global rule (2%-5ms) we could instead have this declared as data with later on a way to automatically update it within the workload.json ?
That would allow an "per workload tolerance" rather than a global once. As for instance I expect the variance for a supabase --version to be much smaller than a supabase start.
I'm thinking if we could have hand-written tolerance per workload in workloads.*.json (for example noisePct: 3 for --version, 20 for db start) that might allow to take the variance/side-effect in consideration better and reduce the false negatives ?
Just an idea and could be done in a follow-up PR though.
Block-scoped workloads judge the median of per-block deltas against the block medians' spread, so one odd stack session can neither flag nor hide a change. Run-scoped workloads keep the base range check and also need the change to clear the launches' spread. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow-up to #7412.
Block-scoped workloads started one stack per block of five launches, so a ten-run workload gave each build only two stack sessions. Launches in one block share a stack session, so session-to-session spread could push the branch median outside the base range, and an A/A run (same CLI code as base and branch) was flagged as slower or faster.
estimatedSecondsfor block-scoped workloads is rescaled for the extra stack sessions, andtracing-monitoring.mddescribes the new rule.False positives may not be entirely eliminated. A follow-up could allow re-running one or more chosen workloads, so a reported regression can be confirmed without re-running the whole benchmark.
🤖 Generated with Claude Code