Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Revert parts of #66405. #67471
Revert parts of #66405. #67471
Conversation
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
Revert parts of #66405. Because it caused major performance regressions in some cases. That PR had five commits, two of which affected performance, and three of which were refactorings. This change undoes the performance-affecting changes, while keeping the refactorings in place. Fixes #67454. r? @nikomatsakis
|
|
|
Queued 1f56c62 with parent ccd2383, future comparison URL. |
|
Finished benchmarking try commit 1f56c62, comparison URL. |
|
Hmm, the perf results don't seem too reflect much improvement? |
|
We've had trouble with the perf results on this PR historically - the perf server is not quite accepting of the wins (or I guess losses too) that @nnethercote manages to measure locally. We're not sure why, though we've mostly eliminated bugs in the perf server itself such as measuring different artifacts. It might be an architecture difference (e.g., @nnethercote is not using AMD chips) but that would be quite surprising to me. |
|
This PR is expected to be a small performance loss on the benchmarks, because it reverts #66405, which was a small performance gain on the benchmarks, mostly for But as @Mark-Simulacrum says, the perf results were very strange for that PR: inconsistent across multiple CI runs, all of which didn't really match my local results. (To the point where I did an experiment in #67248 to make sure the right revisions were being tested; they were.) And the results above are equally inconsistent, with as many wins as there are losses. And I have no idea why Anyway, overall I think we should land this because it has minimal effect on the benchmark suite, but is known to fix some catastrophic performance regressions for real-world programs outside the benchmark suite (in #67454 and #67331). We should also backport this to beta, so that no rustc release contains the regression. I won't have a chance to analyze what went wrong in #66405 until I get back from PTO in late January, unfortunately. One could also argue that the test program in #67454 should be added to the benchmark suite to prevent future regressions of this sort. |
Can code in the benchmarks depend on external crates? If so I can prepare a PR for this. |
They can, and most of them do! |
|
Perfect, took me a while to find the right repo but here it is: rust-lang/rustc-perf#588 :) |
|
What's blocking this to be merged? |
|
Nothing, sorry, r=me -- but needs rebase |
|
From #67454 (comment)
Since they return ~a day before the next release, someone else with permissions might need to handle the rebase. |
|
I will rebase and r=niko shortly. |
694e593
to
d9f1450
|
@bors r=nikomatsakis rollup=never |
|
|
|
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Because it caused major performance regressions in some cases. That PR had five commits, two of which affected performance, and three of which were refactorings. This change undoes the performance-affecting changes, while keeping the refactorings in place. Fixes #67454.
d9f1450
to
18a3669
|
@bors r=nikomatsakis rollup=never |
|
|
Revert parts of #66405. Because PR #66405 caused major performance regressions in some cases. That PR had five commits, two of which affected performance, and three of which were refactorings. This change undoes the performance-affecting changes, while keeping the refactorings in place. Fixes #67454. r? @nikomatsakis
|
|
|
Many thanks, compilation times for this use case are back to normal on nightly now. Friendly reminder, @nnethercote commented:
|
|
discussed at T-compiler meeting. Accepted for beta-backport. |
[beta] backports This backports: * Do not ICE on malformed suggestion spans #68256 * Distinguish between private items and hidden items in rustdoc #67875 * Revert parts of #66405. #67471 It also includes a few formatting commits to permit the backports to proceed cleanly (those are scoped to the relevant files, but still generate noise, of course). This was deemed easier than attempting to manually deal with the formatting. r? @ghost
[beta] backports This backports: * Do not ICE on malformed suggestion spans #68256 * Distinguish between private items and hidden items in rustdoc #67875 * Revert parts of #66405. #67471 It also includes a few formatting commits to permit the backports to proceed cleanly (those are scoped to the relevant files, but still generate noise, of course). This was deemed easier than attempting to manually deal with the formatting. r? @ghost
Because PR #66405 caused major performance regressions in some cases.
That PR had five commits, two of which affected performance, and three
of which were refactorings. This change undoes the performance-affecting
changes, while keeping the refactorings in place.
Fixes #67454.
r? @nikomatsakis