Avoid closures to improve compile times.#183
Merged
bors merged 1 commit intorust-lang:masterfrom Aug 7, 2020
Merged
Conversation
Contributor
Author
|
Here are some measurements from my Linux box, measuring |
`HashMap` and `HashSet` are used widely, and often instantiated many times. As a result, small differences in how the code is written can have a significant effect on how much LLVM IR is generated, which affects compile times. This commit avoids a lot of small closures by replacing calls to `Option::map`, `Option::ok_or_else`, `Option::unwrap_or_else` and `Result::unwrap_or_else` with `match` expressions. Although this makes the code less concise, it improves compile times. For example, several of the benchmarks in rustc-perf compile up to 3.5% faster after this change is incorporated into std. Every change is accompanied by a short comment to explain why a `match` is used. This may seem excessive, but without these comments it would be easy for a well-meaning person in the future to change some or all of these back to the original versions without understanding the consequences.
7d359d7 to
e47bec1
Compare
Member
|
@bors r+ |
Contributor
|
📌 Commit e47bec1 has been approved by |
Contributor
Contributor
|
☀️ Test successful - checks-travis |
Contributor
Author
|
@Amanieu: I know that hashbrown was just upgraded in std to 0.8.1, but I think it would be worth doing a 0.8.2 release with this change so that the compile time benefits can be spread widely? |
Member
|
Sure, I'll do that after #184 is merged. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 9, 2020
Update hashbrown to 0.8.2 Includes: - Avoid closures to improve compile times (rust-lang/hashbrown#183) - Do not iterate to drop if empty (rust-lang/hashbrown#182) r? @Mark-Simulacrum
jonhoo
pushed a commit
to jonhoo/griddle
that referenced
this pull request
Aug 9, 2020
Port of the relevant changes from hashbrown from rust-lang/hashbrown#183
Amanieu
added a commit
to Amanieu/hashbrown
that referenced
this pull request
Mar 4, 2021
We manually expand these to reduce the amount of LLVM IR generated. (rust-lang#183)
bors
added a commit
that referenced
this pull request
Mar 4, 2021
Allow clippy::manual_map We manually expand these to reduce the amount of LLVM IR generated. (#183)
This file contains hidden or 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
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.
HashMapandHashSetare used widely, and often instantiated manytimes. As a result, small differences in how the code is written can
have a significant effect on how much LLVM IR is generated, which
affects compile times.
This commit avoids a lot of small closures by replacing calls to
Option::map,Option::ok_or_else,Option::unwrap_or_elseandResult::unwrap_or_elsewithmatch` expressions. Although this makesthe code less concise, it improves compile times. For example, several
of the benchmarks in rustc-perf compile up to 3.5% faster after this
change is incorporated into std.
Every change is accompanied by a short comment to explain why a
matchis used. This may seem excessive, but without these comments it would be
easy for a well-meaning person in the future to change some or all of
these back to the original versions without understanding the
consequences.