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

fix dropck performance regression #30368

Merged
merged 1 commit into from
Dec 16, 2015
Merged

Conversation

arielb1
Copy link
Contributor

@arielb1 arielb1 commented Dec 13, 2015

Turns out that calling resolve_type_variables_if_possible in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).

Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
@arielb1
Copy link
Contributor Author

arielb1 commented Dec 13, 2015

r? @nikomatsakis

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Dec 15, 2015

📌 Commit 08bffdd has been approved by nikomatsakis

@nikomatsakis
Copy link
Contributor

Note though that it is STILL possible for the resolution to change and thus for us to recurse a little more than we 'ought' to -- but it should reach a stable state, presumably.

Manishearth added a commit to Manishearth/rust that referenced this pull request Dec 16, 2015
…omatsakis

Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
Manishearth added a commit to Manishearth/rust that referenced this pull request Dec 16, 2015
…omatsakis

Turns out that calling `resolve_type_variables_if_possible` in a O(n^2)
loop is a bad idea. Now we just resolve each copy of the region variable
to its lowest name each time (we resolve the region variable to its lowest
name, rather than to its unify-table name to avoid the risk of
the unify-table name changing infinitely many times. That may be
not a problem in practice, but I am not sure of it).
bors added a commit that referenced this pull request Dec 16, 2015
@bors bors merged commit 08bffdd into rust-lang:master Dec 16, 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