consolidate type-variable handling in assemble_candidates #27984
Conversation
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
|
Nice patch. r+ modulo nits. |
this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of `assemble_candidates_from_projected_tys`).
In both these cases, `assemble_candidates_from_impls` would try to go
over all impls and match them, leading to O(n*m) performance. Fixing this
improves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but *does*
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
echo '#![feature(rustc_private)]'
echo 'extern crate rustc_driver;'
for i in {1..1000}; do cat << _EOF_
pub fn foo$i<T>() {
let mut v = Vec::new();
let _w = v.clone();
v.push("");
}
_EOF_
done
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
arielb1
force-pushed
the
misc-assemble-improvements
branch
from
35cfb91 to
ab86bf5
Compare
|
updated |
|
@bors r+ |
|
📌 Commit ab86bf5 has been approved by |
|
⌛ Testing commit ab86bf5 with merge 1d2c20b... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit ab86bf5 with merge b399f8d... |
|
⛄ The build was interrupted to prioritize another pull request. |
bors
added a commit
that referenced
this pull request
Sep 4, 2015
…akis
this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of `assemble_candidates_from_projected_tys`).
In both these cases, `assemble_candidates_from_impls` would try to go
over all impls and match them, leading to O(`n*m`) performance. Fixing this
improves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but *does*
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
```
echo '#![feature(rustc_private)]'
echo 'extern crate rustc_driver;'
for i in {1..1000}; do cat << _EOF_
pub fn foo$i<T>() {
let mut v = Vec::new();
let _w = v.clone();
v.push("");
}
_EOF_
done
```
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
r? @nikomatsakis
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.
this resolves type-variables early in assemble_candidates and
bails out quickly if the self type is an inference variable (which would
fail anyway because of
assemble_candidates_from_projected_tys).In both these cases,
assemble_candidates_from_implswould try to goover all impls and match them, leading to O(
n*m) performance. Fixing thisimproves rustc type-checking performance by 10%. As type-checking is only
is 5% of compilation, this doesn't impact bootstrap times, but does
improve type-error-detection time which is nice.
Crates that have many dependencies and contain significant amounts of
generic functions could see a bigger perf boost. As a microbenchmark,
the crate generated by
sees performance improve from 7.2 to 1.4 seconds. I imagine many crates
would fall somewhere in-between.
r? @nikomatsakis