Uh oh!
There was an error while loading. Please reload this page.
Improve derived implementations for enums with lots of fieldless variants - #33593
Merged
Conversation
rust-highfive
commented
May 12, 2016
Contributor
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
brson
commented
May 12, 2016
Contributor
@bors r+ |
bors
commented
May 12, 2016
Collaborator
📌 Commit 3d651e6 has been approved by |
…ants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant, because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all, the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum, this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair, most other crates don't benefit nearly as much, because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.
dotdash
commented
May 12, 2016
ContributorAuthor
@bors r=brson Fixed the tests. |
bors
commented
May 12, 2016
Collaborator
📌 Commit 0eeb14e has been approved by |
eddyb added a commit
to eddyb/rust
that referenced
this pull request
May 13, 2016
Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant, because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all, the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum, this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair, most other crates don't benefit nearly as much, because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.
bors
commented
May 14, 2016
Collaborator
⌛ Testing commit 0eeb14e with merge cdaa601... |
bors
commented
May 15, 2016
Collaborator
💔 Test failed - auto-mac-32-opt |
arielb1
commented
May 15, 2016
Contributor
random timeout @bors retry |
bors
commented
May 15, 2016
Collaborator
bors added a commit
that referenced
this pull request
May 15, 2016
Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant, because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all, the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum, this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair, most other crates don't benefit nearly as much, because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.
bors
commented
May 15, 2016
Collaborator
nox added a commit
to servo/servo
that referenced
this pull request
May 17, 2016
nox added a commit
to servo/servo
that referenced
this pull request
May 17, 2016
zakorgy pushed a commit
to zakorgy/servo
that referenced
this pull request
May 26, 2016
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
A number of trait methods like PartialEq::eq or Hash::hash don't
actually need a distinct arm for each variant, because the code within
the arm only depends on the number and types of the fields in the
variants. We can easily exploit this fact to create less and better
code for enums with multiple variants that have no fields at all, the
extreme case being C-like enums.
For nickel.rs and its by now infamous 800 variant enum, this reduces
optimized compile times by 25% and non-optimized compile times by 40%.
Also peak memory usage is down by almost 40% (310MB down to 190MB).
To be fair, most other crates don't benefit nearly as much, because
they don't have as huge enums. The crates in the Rust distribution that
I measured saw basically no change in compile times (I only tried
optimized builds) and only 1-2% reduction in peak memory usage.