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

Avoid O(n^2) performance by checking reduced set of obligations #18386

Merged
merged 1 commit into from
Oct 28, 2014

Conversation

nikomatsakis
Copy link
Contributor

Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like let x: Vec<_> = obligations.iter().collect() work.

I think we lack the infrastructure to write a regression test for this, but when I did manual testing I found a massive reduction in type-checking time for extreme examples like those found in #18208 vs stage0.

f? @dotdash

@nikomatsakis
Copy link
Contributor Author

In truth, I don't think we need to be so eager about selecting new obligations. We should probably wait until we want information we don't have, and then try new-obligations and finally all obligations.

@nikomatsakis nikomatsakis changed the title Avoid O(n^2) performance by reconsidering the full set of obligations Avoid O(n^2) performance by checking reduced set of obligations Oct 28, 2014
@pnkfelix
Copy link
Member

lgtm, feel free to r=me after squashing.

… only when we are about to report an error (rust-lang#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work.
bors added a commit that referenced this pull request Oct 28, 2014
Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work.

I think we lack the infrastructure to write a regression test for this, but when I did manual testing I found a massive reduction in type-checking time for extreme examples like those found in #18208 vs stage0.

f? @dotdash
@dotdash
Copy link
Contributor

dotdash commented Oct 28, 2014

LGTM, type checking can now handle enough println!("Hello world") lines in just a few seconds to make liveness checking fail with an oom :-D

@nikomatsakis
Copy link
Contributor Author

@dotdash yeah. I think there's still room to do much better (see #18391) but this patch at least removes the immediate pain.

@bors bors closed this Oct 28, 2014
@bors bors merged commit 1da73ff into rust-lang:master Oct 28, 2014
@nikomatsakis nikomatsakis deleted the issue-18208 branch March 30, 2016 16:13
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.

4 participants