Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consolidate type-variable handling in assemble_candidates #27984

Merged
merged 1 commit into from
Sep 4, 2015

Conversation

arielb1
Copy link
Contributor

@arielb1 arielb1 commented Aug 24, 2015

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

@nikomatsakis
Copy link
Contributor

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
Copy link
Contributor Author

arielb1 commented Sep 2, 2015

updated

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 3, 2015

📌 Commit ab86bf5 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Sep 3, 2015

⌛ Testing commit ab86bf5 with merge 1d2c20b...

@bors
Copy link
Contributor

bors commented Sep 3, 2015

⛄ The build was interrupted to prioritize another pull request.

@bors
Copy link
Contributor

bors commented Sep 3, 2015

⌛ Testing commit ab86bf5 with merge b399f8d...

@bors
Copy link
Contributor

bors commented Sep 3, 2015

⛄ 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
@bors
Copy link
Contributor

bors commented Sep 4, 2015

⌛ Testing commit ab86bf5 with merge 2727a8e...

@bors bors merged commit ab86bf5 into rust-lang:master Sep 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants