Change match desugaring in MIR to be O(n) instead of O(n^2) #29763
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
pass around references instead of boxed values to save on clone costs.
before we iterated over the test and each outcome thereof, and then checked processed every candidate against this outcome, we now organize the walk differently. Instead, we visit each candidate and say "Here is the test being performed. Figure out the resulting candidates for each possible outcome and add yourself into the appropriate places."
|
Looks good to me. r=me with that one change. |
|
@bors r=aatch |
|
📌 Commit 0a4d6fe has been approved by |
|
⌛ Testing commit 0a4d6fe with merge daa72e2... |
|
💔 Test failed - auto-linux-64-nopt-t |
`Vec` should not be resized.
nikomatsakis
force-pushed
the
mir-29227
branch
from
0a4d6fe
to
3b903a7
Compare
|
@bors r=aatch (queue is basically empty, so I'll keep abusing bors, since my local build is being slow) |
|
📌 Commit 3b903a7 has been approved by |
|
⌛ Testing commit 3b903a7 with merge 138f45a... |
|
💔 Test failed - auto-mac-64-opt |
|
@bors r+ fml |
|
📌 Commit 38cf175 has been approved by |
bors
added a commit
that referenced
this pull request
Nov 11, 2015
The older algorithm was pretty inefficient for big matches. Fixes #29227. (On my computer, MIR construction on this test case goes from 9.9s to 0.025s.) Whereas before we had a loop like: - for all outcomes of the test we are performing - for all candidates - check whether candidate is relevant to outcome We now do: - for all candidates - determine which outcomes the candidate is relevant to Since the number of outcomes in this case is proportional to the number of candidates, the original algorithm turned out to be O(n^2), and the newer one is just O(n). This PR also does some minor speedups by eagerly mirroring all patterns, so that we can just pass around `&Pattern<'tcx>`, which makes cloning cheaper. We could probably go a bit further in this direction. r? @Aatch
This was referenced Nov 11, 2015
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Nov 12, 2015
In previous PRs, I changed the match desugaring to generate more efficient code for ints/chars and the like. But this doesn't help when you're matching strings, ranges, or other crazy complex things (leading to rust-lang#29740). This commit restructures match desugaring *yet again* to handle that case better -- basically we now degenerate to an if-else-if chain in such cases. ~~Note that this builds on rust-lang#29763 which will hopefully land soon. So ignore the first few commits.~~ landed now r? @Aatch since he's been reviewing the other commits in this series
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.
The older algorithm was pretty inefficient for big matches. Fixes #29227. (On my computer, MIR construction on this test case goes from 9.9s to 0.025s.) Whereas before we had a loop like:
We now do:
Since the number of outcomes in this case is proportional to the number of candidates, the original algorithm turned out to be O(n^2), and the newer one is just O(n).
This PR also does some minor speedups by eagerly mirroring all patterns, so that we can just pass around
&Pattern<'tcx>, which makes cloning cheaper. We could probably go a bit further in this direction.r? @Aatch