Repository navigation
ci(bench): remove run drift and raise the noise floor in the PR comment - #60
Conversation
Divide the median change of the control rows out of the Patternia deltas, so a systematic offset between the two runs is not read as a change, and raise the minimum noise threshold from 3% to 5%. The comment shows the adjusted delta next to the raw one and says how the offset was estimated.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Benchmark comparison (informational)Base Noise estimate: the 20 control rows below do not run Patternia code, so they should not change between base and PR. As a group they moved by a median of -0.0% (run order and machine drift); that offset is divided out of the Patternia deltas (Adjusted). The controls then scatter by a median of 0.1%. Adjusted differences under 5.0% are treated as noise. Patternia: 8 benchmarks, 0 slower, 0 faster, 8 within noise.
Control rows (not Patternia code)
Raw results and the comparison chart are attached to this workflow run as an artifact. Shared runners are noisy, so use this as a trend, not a measurement. |
Summary
Follow-up to the PR benchmark comment. The first real run of the comment (on #59, a pull request that changes no benchmark code) showed two things: the later run came out systematically faster than the earlier one, and one Patternia row was marked "faster" although nothing had changed. This change tries to account for the first and makes the verdict more conservative. It is a heuristic and, on the data available, it only partly helps; the limits are listed below.
Changes
scripts/bench_pr_comment.py: take the median signed change of the control rows (the implementations that do not run Patternia code) as the offset the later run picked up from run order and machine drift, and divide it out of the Patternia deltas.max(5%, 2 x scatter).Adjustedcolumn next to the rawDelta, and the verdict is based onAdjusted. With fewer than three control rows the offset cannot be estimated, so the comment falls back to raw deltas against the 5% floor and says so.Testing
python3 -m py_compilepasses.Limits on real data (please read before relying on the verdicts)
I re-ran the script on the real artifact of #59, a run with no code change, which is the only real sample I have:
PacketMixedis still marked "faster": raw -6.8%, adjusted -5.4%, against a threshold of 5.0%. The false positive is therefore only reduced to a borderline case, not removed.More principled alternatives, not done here: run base, PR, base, PR and use the difference between the two runs of the same binary as that benchmark's own noise (about 10 more minutes of job time), or also require a multiple of each benchmark's coefficient of variation.