-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustdoc: Box GenericArgs::Parenthesized.output
#88522
Conversation
5d3e08a
to
074d79f
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 074d79f0e66ed08d6bf514523314a6e27f6a48f0 with merge 51d7bb9752da9a4aa758f2dab28c1b56245687ed... |
☀️ Try build successful - checks-actions |
Queued 51d7bb9752da9a4aa758f2dab28c1b56245687ed with parent 6f388bb, future comparison URL. |
Finished benchmarking try commit (51d7bb9752da9a4aa758f2dab28c1b56245687ed): comparison url. Summary: This benchmark run did not return any relevant changes. 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. @bors rollup=never |
max-rss looks to have improved by between 0.8% and 1.6% for several benchmarks, with no significant regressions. instruction count is unchanged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rustc_assert_size
is the only change I feel strongly about, the rest you can choose to add or not. Good catch! I wouldn't have found this :)
output: if output != Type::Tuple(Vec::new()) { Some(output) } else { None }, | ||
} | ||
let output = | ||
if output != Type::Tuple(Vec::new()) { Some(Box::new(output)) } else { None }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I would use box output
here 🤷 but it won't affect performance in practice, output
is already on the stack.
Oh, this is the bit that breaks #83718 (comment) ! I've been looking for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I would use
box output
here 🤷
Yeah, I thought about that, but someone recently removed all the uses of box_syntax
from rustdoc and other tools; I think the goal is to get rid of box_syntax
eventually. IIRC from the discussion there, the newest version of LLVM has an optimization that gets rid of the perf difference, but I may be misremembering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, this is the bit that breaks #83718 (comment) ! I've been looking for it.
Hooray! 🎉
GenericArgs::Parenthesized.output
GenericArgs::Parenthesized.output
074d79f
to
3a0b073
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me unless you want to try boxing GenericArgs
src/librustdoc/clean/types.rs
Outdated
#[derive(Clone, PartialEq, Eq, Debug, Hash)] | ||
crate struct PathSegment { | ||
crate name: Symbol, | ||
crate args: GenericArgs, | ||
} | ||
|
||
// `PathSegment` occurs multiple times in every `Path`, so its size can | ||
// significantly affect rustdoc's memory usage. | ||
rustc_data_structures::static_assert_size!(PathSegment, 64); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this is a good point - I wonder whether it hurts or helps to box GenericArgs instead of output
? Are you interested in making another perf run with that change? (no problem if not, this is still a good perf improvement as-is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I just saw your comment now; I wonder if there was a glitch in GitHub.
The thing is that GenericArgs
is constructed for every PathSegment
, so I think rustdoc would still be allocating the same amount of memory as without the Box
(in fact, a bit more, because of the usize
for the Box
). Whereas with the change I made, the Box
is only constructed if (a) the GenericArgs
is for Fn
sugar and (b) the Fn
sugar has an output type.
However, making PathSegment.args
an Option<Box<GenericArgs>>
that would be None
if there were no GenericArgs
(the common case) could give us a nice perf win. One problem with that is that we would then have multiple ways to represent no GenericArgs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, writing up that comment just gave me an idea for another way to improve perf :D
Here it is: #88574
3a0b073
to
c3ceee1
Compare
This comment has been minimized.
This comment has been minimized.
This reduces the size of `GenericArgs` from 104 bytes to 56 bytes, essentially reducing it by half. `GenericArgs` is one of the fields of `PathSegment`, so this should reduce the amount of memory allocated for `PathSegment`s in the cases where the generics are not for a `Fn`, `FnMut`, or `FnOnce` trait. I also added `static_assert_size!`s to `GenericArgs` and `PathSegment` to ensure they don't increase in size unexpectedly.
c3ceee1
to
280e167
Compare
@bors r+ |
📌 Commit 280e167 has been approved by |
☀️ Test successful - checks-actions |
Split out from #88379.
This reduces the size of
GenericArgs
from 104 bytes to 56 bytes,essentially reducing it by half.
GenericArgs
is one of the fields ofPathSegment
, so this shouldreduce the amount of memory allocated for
PathSegment
s in the caseswhere the generics are not for a
Fn
,FnMut
, orFnOnce
trait.r? @jyn514