Skip to content

ci: confirm cargo bench regressions with a targeted rerun - #38810

Open
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:cargo-bench-confirm
Open

ci: confirm cargo bench regressions with a targeted rerun#38810
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:cargo-bench-confirm

Conversation

@antiguru

Copy link
Copy Markdown
Member

Motivation

The first scheduled run of the cargo-bench step (nightly build 18289) flagged regressions of +21% to +167% across four shards. None of them held up. Local runs at the same two commits flagged a different set of rows each time, and rerunning one pair of identical binaries flagged a third set, always on the 8M and 128M inputs and always with a confidence interval under one percentage point. Criterion's interval covers the variance inside one process. The variance between processes on large inputs is what dominates, and it is far above the 10% threshold.

Description

A benchmark that regresses in the first pass is measured again, both sides, filtered to exactly the flagged benchmark ids through criterion's regex filter, into a separate criterion home so the first pass stays intact. A regression counts only when both passes agree. A rerun that disagrees, or that produced no result, leaves the row as unconfirmed, shown in the table with its rerun delta and never failing the step. The cost scales with the number of flagged rows and is zero when there are none, so it adds nothing to the common case.

The results table now opens its own Buildkite log group instead of landing inside the last benchmark's collapsed section.

Smoke on mz-repr across the Row decode change with --threshold 0.0: 21 first-pass regressions, 8 confirmed, 13 unconfirmed. One row read +48.2% in the first pass and −0.3% on the rerun.

Unit tests cover a confirmed regression, a downgraded one, and a rerun missing the benchmark.


Posted by Claude Code.

🤖 Generated with Claude Code

The first scheduled run of the cargo-bench step flagged regressions of up
to +167% on inputs of 8M and 128M rows. None reproduced: local runs at the
same commits flagged different rows each time, and a rerun of one pair of
identical binaries moved a third set. Criterion's interval only covers the
variance inside one process, while the variance between processes on
large inputs is far above the threshold.

A benchmark that regresses in the first pass is now measured again, both
sides, filtered to exactly the flagged ids through criterion's regex
filter, into a separate criterion home so the first pass stays intact. A
regression counts only when both passes agree. A rerun that disagrees, or
that produced no result, leaves the row as `unconfirmed`, shown in the
table with its rerun delta and never failing the step. The cost scales
with the number of flagged rows, nothing when there are none.

The results table also opens its own Buildkite log group instead of
landing inside the last benchmark's collapsed section.

Co-Authored-By: Claude Fable 5.1 <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