See the README for details on how this log was gathered.
This week was a disaster, perf-wise. 28 revisions checked. 7 regressions, several of them ranging from large to huge, many in rollups. Some additional regressions may have occurred in rollups that were masked by other regressions/improvements. 3 improvements, one of which was a reversion of a regression. Thanks for Mark-Simulacrum and eddyb for follow-up measurements and adding new tooling to help investigate regressions in rollups. A follow-up thread on Zulip is here.
In better news, rustdoc performance is now being benchmarked, thanks to the efforts of Joshua Nelson.
Triage done by njn. Revision range: 9d09331e00b02f81c714b0c41ce3a38380dd36a2..71384101ea3b030b80f7def80a37f67e148518b0.
Regressions
layout_of
calls in const eval. #74202 (instructions): Up to 2% losses on one benchmark.Improvements
SymbolName::name
to a &str
. #74214 (instructions): Up to 2.5% wins on numerous benchmarks.everybody_loops
for rustdoc; instead ignore resolution errors #73566 (instructions): Wins of up to 62.6% and losses of up to 8.5%, all on rustdoc builds. Overall, the improvements greatly outweigh the losses. (Landed in rollup #74408.)Rollup of 11 pull requests #74468
This rollup was originally judged as responsible for a 10% regression in instrutions:u. However, since then, it has been determined that the likely cause of this regression is actually perf‘s move to using x.py dist
-shipped std’s rather than building one locally. Investigation into why this move caused a regression is as yet not done, but is being tracked in rustc-perf#724.
Initially #74069 and/or #72414 were suspected as the cause of the regression, but further testing showed that to not be the case.
We have since opened a PR to re-land #74069, as well: #74802.