Repository navigation
ci: split the simulation benchmarks into shards by measured time - #22876
alexander-akait wants to merge 1 commit into
Conversation
|
|
This PR is packaged and the instant preview of its latest commit is available. Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@22876
yarn add -D webpack@https://pkg.pr.new/webpack@22876
pnpm add -D webpack@https://pkg.pr.new/webpack@22876 |
Types CoverageCoverage after merging ci/balance-benchmark-shards into main will be
Coverage Report |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ➖ Normal Change: Other Merge Risk: ⚪ Minimal · up to
|
Generated code sizeComparing base (
Read No asset changed size. No runtime gained or lost a runtime module. Built |
Merging this PR will improve performance by 40.48%2 warnings, 1 note
Performance Changes
Tip Curious why performance improved? Comment Comparing |
Summary
On PRs the run isn't finished until the slowest benchmark shard is: it ends ~66 min after the run starts, while every other job is done by ~38 min. The 6 simulation shards are dealt round-robin, so they range from 25 to 59 min.
The shards are now split by measured time:
test/benchmarkTimings.jsonholds each task's seconds, taken from the logs of the last two green runs. Tasks go longest first, each to the shard with the least time so far. Every shard computes the same split independently. A task missing from the file counts as the median, so a new benchmark still runs. Memory mode keeps round-robin, since its two shards are already even (12–13 min).Measured work per shard (minutes):
Real runs vary per task by up to ±25%, so I expect the slowest shard at ~45–48 min instead of 52–59.
It also carries the one-line
ParserOptionstypedef from #22875, without whichlintfails onmain. It no-ops once #22875 lands.What kind of change does this PR introduce?
ci
Did you add tests for your changes?
No. I checked the split locally against the timings: each of the 226 tasks lands on exactly one shard, and an unknown task gets a shard. The benchmark jobs on this PR are the real check.
Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
n/a
Use of AI
Claude Code measured the shard times from CI logs and wrote the change on my request.
Generated by Claude Code
Summary by CodeRabbit