stop applying noinline to glue code #4931
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bors
added a commit
that referenced
this pull request
Feb 14, 2013
Using `noinline` causes a 3-10% hit in performance for most compiled Rust code. For the TreeMap it's ~15% and that's where I first noticed it. Removing the noinline attribute doesn't slow down unoptimized builds, but it does significantly increase the time spent in LLVM passes for optimized builds. The improved speed of the compiler actually improves compile-times when optimization is off. However, the reason for the increase is because more optimization is being done - I'm sure it would speed up compiles to mark *everything* with noinline, but it wouldn't be a good idea. LLVM is clever enough with the inlining heuristics that this doesn't cause a notable increase in code size - some code becomes a bit bigger, some becomes a bit smaller. There are some cases where it's able to strip out a ton of code thanks to inlining. I tried out `optsize` for glue code instead but it caused the same hit for LLVM passes in the compile time and the compiled code was a bit slower than just trusting LLVM to make the decisions. * [TIME_PASSES=1 benchmarks](http://ompldr.org/vaGdxaA) (showing the performance increase in `rustc` and also the extra time spent in LLVM passes for more optimization)
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jun 30, 2023
new lint: `manual_range_patterns` Fixes rust-lang#4931 changelog: new lint: [`manual_range_patterns`]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using
noinlinecauses a 3-10% hit in performance for most compiled Rust code. For the TreeMap it's ~15% and that's where I first noticed it.Removing the noinline attribute doesn't slow down unoptimized builds, but it does significantly increase the time spent in LLVM passes for optimized builds. The improved speed of the compiler actually improves compile-times when optimization is off.
However, the reason for the increase is because more optimization is being done - I'm sure it would speed up compiles to mark everything with noinline, but it wouldn't be a good idea.
LLVM is clever enough with the inlining heuristics that this doesn't cause a notable increase in code size - some code becomes a bit bigger, some becomes a bit smaller. There are some cases where it's able to strip out a ton of code thanks to inlining.
I tried out
optsizefor glue code instead but it caused the same hit for LLVM passes in the compile time and the compiled code was a tiny bit slower than just trusting LLVM to make the decisions.rustcand also the extra time spent in LLVM passes for more optimization)