-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Remove remaining uses of box syntax from librustdoc #99577
Conversation
r? @jsha (rust-highfive has picked a reviewer for you, use r? to override) |
@compiler-errors or someone else, can this get a perf run? Thanks! |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 0d2249c6cda35aba6cb90bd71ab5e3d46a4c4c42 with merge e4d4199ad31d4d6bdac9a4468e32c2738164fdb0... |
0d2249c
to
8b057c8
Compare
@bors try |
⌛ Trying commit 8b057c808bcb640077f948f3bd4773ce6e04f51c with merge 5290cb7cfb03f6f9a07b09bdac69135e2aaa4a05... |
☀️ Try build successful - checks-actions |
Queued 5290cb7cfb03f6f9a07b09bdac69135e2aaa4a05 with parent aa01891, future comparison URL. |
Finished benchmarking commit (5290cb7cfb03f6f9a07b09bdac69135e2aaa4a05): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
I'm only looking at the performance changes related to doc builds as this PR only changes librustdoc. There are up to 0.43% improvements in instruction count and up to 2.71% regression in max-rss (memory usage). The latter is weird because it's supposed to reduce memory overhead. Of course the extra indirection and extra number of allocations do have a footprint that needs to be earned back by the halving of the enum size, aka if sufficiently large percentage of uses of the enum were bigger variants, then obviously more memory is going to be used due to the indirection. But I don't think that this case is ever hit, as "sufficiently large" requires almost all uses of it to be, because a pointer and an extra allocation don't take up that much extra space. It might just be noise, idk. What's really important is that the characteristic 0.4% regression that originally plagued #99066 and its preceeding attempts is gone (picture from this perf run): Now it's like: Which is way nicer :). I think this means that the performance issues of the box removal are resolved. I'll soon make the PR ready for merging and will ask for a review. |
bc93d59
to
7b8aa7f
Compare
Some changes occurred in src/librustdoc/clean/types.rs cc @camelid |
r? @jsha it's ready for review now. |
☔ The latest upstream changes (presumably #99652) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks! Can you resolve the merge conflicts? |
7b8aa7f
to
46311b7
Compare
@jsha rebased. |
☔ The latest upstream changes (presumably #99892) made this pull request unmergeable. Please resolve the merge conflicts. |
The type has 240 bytes according to compiler internal rustdoc.
This reduces ItemKind size from 224 bytes to 160 bytes.
This reduces ItemKind size from 160 bytes to 112 bytes
46311b7
to
fabb4b0
Compare
@jsha rebased again. |
@bors r+ Thanks! |
☀️ Test successful - checks-actions |
Finished benchmarking commit (3924dac): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Remove the remaining uses of box syntax from librustdoc. Followup of #99066 where these changes were split out because they were responsible for a small but noticeable regression. This PR avoids the regression by boxing some large variants of
ItemKind
to reduce the enum's size by half from 224 bytes to 112 bytes (on x86-64). This should also help with reducing memory usage.