-
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
Add #[inline] to small functions in core #116583
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Add #[inline] to small functions in core Where "small" is strictly defined as optimized_mir with 5 or less statements and no calls. I've also applied that heuristic recursively; applying it once causes some functions to become eligible for MIR inlining bring other functions under the threshold. r? `@ghost`
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (fcd818f): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 627.383s -> 626.833s (-0.09%) |
e50157c
to
69b3155
Compare
I'm going to try a slightly different approach just to see what happens- this time I'm adding |
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Add #[inline] to small functions in core Where "small" is strictly defined as optimized_mir with 5 or less statements and no calls. I've also applied that heuristic recursively; applying it once causes some functions to become eligible for MIR inlining which brings other functions under the threshold. r? `@ghost`
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (b1ac082): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 626.852s -> 625.243s (-0.26%) |
69b3155
to
ab949b8
Compare
Add #[inline] to small functions in core I'm adding a new case to the definition of cross-crate-inlinable; we know that making the definition too broad causes huge regressions in incremental builds. So implementing broader heuristics as a machine-applicable lint means that I can `x fix --stage 1 library/core` to apply the new heuristic just to the standard library. I expect that applying the broader heuristic just to the standard library will have a different effect than applying the change globally.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (d11ea83): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 635.521s -> 654.274s (2.95%) |
9c3c8ef
to
4edca85
Compare
That looks like it might be moving in a good direction? Notably the big improvements are all in |
This comment has been minimized.
This comment has been minimized.
Add #[inline] to small functions in core I'm adding a new case to the definition of cross-crate-inlinable; we know that making the definition too broad causes huge regressions in incremental builds. So implementing broader heuristics as a machine-applicable lint means that I can `x fix --stage 1 library/core` to apply the new heuristic just to the standard library. I expect that applying the broader heuristic just to the standard library will have a different effect than applying the change globally.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (79d9fa0): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 637.169s -> 642.023s (0.76%) |
Wow that is not the direction I expected. |
Emit #[inline] on derive(Debug) Breaking out part of rust-lang#116583 (comment) r? `@ghost`
Emit #[inline] on derive(Debug) Breaking out part of rust-lang#116583 (comment) r? `@ghost`
…ercote Emit #[inline] on derive(Debug) While working on rust-lang#116583 I noticed that the `cross_crate_inlinable` query identifies a lot of derived `Debug` impls as a MIR body that's little more than a call, which suggests they may be a good candidate for `#[inline]`. So here I've implemented that change specifically. It seems to provide a nice improvement to build times.
4edca85
to
20e1c0e
Compare
I'm not actually planning to move this PR forward; this was an experiment that resulted in adding A lint that suggests |
I'm adding a new case to the definition of cross-crate-inlinable; we know that making the definition too broad causes huge regressions in incremental builds. So implementing broader heuristics as a machine-applicable lint means that I can
x fix --stage 1 library/core
to apply the new heuristic just to the standard library. I expect that applying the broader heuristic just to the standard library will have a different effect than applying the change globally.