-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove CrateNum::ReservedForIncrCompCache #85829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit fdfdd08ec59ae3fb47418f2310df75f309cc79df with merge 27edab0bf18b4e2d6617cc3ef49435e245632939... |
This comment has been minimized.
This comment has been minimized.
fdfdd08
to
1ef9885
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 1ef9885 with merge b45d930d4f71d9f1f424a759cf6e02d3c790eb7c... |
☀️ Try build successful - checks-actions |
Queued b45d930d4f71d9f1f424a759cf6e02d3c790eb7c with parent 2023cc3, future comparison URL. |
Finished benchmarking try commit (b45d930d4f71d9f1f424a759cf6e02d3c790eb7c): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Wow! Up to 11.3% improvements for such a simple change! Bootstrap improved by 1.0%. No regressions at all. ❤️ |
@bors r+ |
📌 Commit 1ef9885 has been approved by |
The perf impact is pretty stunning. I think we should try look into exactly why this is such a large improvement - I suspect that there could be similar missed opportunities within rustc. |
No data for |
I would expect that part of the perf change is from the
Huh, strange. |
rustc_parse_format has a runtime of ~1 second, and we don't currently record measurements less than 1 second. |
@bors r+ |
📌 Commit 5ab25ab has been approved by |
⌛ Testing commit 5ab25ab with merge f80975701db776f6a437e4b1a144cba8168ca6b4... |
💥 Test timed out |
x86_64-apple has been running for over 4 hours. All other jobs passed. Likely spurious. @bors retry |
☀️ Test successful - checks-actions |
Post merge perf results: https://perf.rust-lang.org/compare.html?start=7f9ab0300cd66f6f616e03ea90b2d71af474bf28&end=625d5a693e4697bcafdd34fd1a38c281acabb8e9&stat=instructions%3Au Still a huge win! |
Do we have some idea for why this was such a large win? It seems like it may be worth investigating as there's likely some more general improvements to be made - the enum previously defined does not seem like it should add overheads, ideally. Maybe we're hashing enums that are size-optimized by unpacking and hashing the discriminant first, even though that's not necessary in practice in at least some cases (e.g., this one, where the hash of the raw bytes would be sort of fine?). |
This is my best guess: #85829 (comment)
Yeah, I am pretty sure this is the case. |
It's only use is easily replaceable with
Option<CrateNum>
.