Skip to content

Use a hash-table when selecting impls #24965

New issue

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

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

Already on GitHub? # to your account

Merged
merged 3 commits into from
May 1, 2015
Merged

Conversation

arielb1
Copy link
Contributor

@arielb1 arielb1 commented Apr 29, 2015

This uses a (per-trait) hash-table to separate impls from different TraitDefs, and makes coherence go so much quicker. I will post performance numbers tomorrow.

This is still WIP, as when there's an overlap error, impls can get printed in the wrong order, which causes a few issues. Should I pick the local impl with the smallest NodeId to print?

Could you take a look at this @nikomatsakis?

@rust-highfive
Copy link
Contributor

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

Ariel Ben-Yehuda added 2 commits April 30, 2015 15:09
The former stopped making sense when we started interning substs and made
TraitRef a 2-word copy type, and I'm moving the latter into an arena as
they live as long as the type context.
Puts implementations in bins hashed by the fast-reject key, and
only looks up the relevant impls, reducing O(n^2)-ishness

Before: 688.92user 5.08system 8:56.70elapsed 129%CPU (0avgtext+0avgdata 1208164maxresident)k, LLVM 379.142s
After: 637.78user 5.11system 8:17.48elapsed 129%CPU (0avgtext+0avgdata 1201448maxresident)k LLVM 375.552s

Performance increase is +7%-ish
@arielb1 arielb1 changed the title [WIP] Use a hash-table when selecting impls Use a hash-table when selecting impls Apr 30, 2015
@arielb1
Copy link
Contributor Author

arielb1 commented Apr 30, 2015

r? @nikomatsakis

@nikomatsakis
Copy link
Contributor

@arielb1

This is still WIP, as when there's an overlap error, impls can get printed in the wrong order, which causes a few issues. Should I pick the local impl with the smallest NodeId to print?

I see that you chose to pick the smallest NodeId, which seems fine -- do you feel this resolves your concern here? (It's not clear to me that there is a "wrong" order, but it'd be easiest and best to stick with the same order as the previous code, I agree, and a consistent order is good for testing.)

@nikomatsakis
Copy link
Contributor

OK, so, r+ but I left a few nits and other questions. Nothing egregious, r=me when you've fixed them (or, if there are things you don't agree with, let me know).

@nikomatsakis
Copy link
Contributor

@bors r+ 30a5448

@huonw
Copy link
Member

huonw commented Apr 30, 2015

I will post performance numbers tomorrow.

Out of interest, did you end up collecting some?

@luqmana
Copy link
Member

luqmana commented May 1, 2015

@huonw: From the second commit message:

Puts implementations in bins hashed by the fast-reject key, and
only looks up the relevant impls, reducing O(n^2)-ishness

Before: 688.92user 5.08system 8:56.70elapsed 129%CPU (0avgtext+0avgdata 1208164maxresident)k, LLVM 379.142s
After: 637.78user 5.11system 8:17.48elapsed 129%CPU (0avgtext+0avgdata 1201448maxresident)k LLVM 375.552s

Performance increase is +7%-ish

bors added a commit that referenced this pull request May 1, 2015
This uses a (per-trait) hash-table to separate impls from different TraitDefs, and makes coherence go so much quicker. I will post performance numbers tomorrow.

This is still WIP, as when there's an overlap error, impls can get printed in the wrong order, which causes a few issues. Should I pick the local impl with the smallest NodeId to print?

Could you take a look at this @nikomatsakis?
@bors
Copy link
Collaborator

bors commented May 1, 2015

⌛ Testing commit 30a5448 with merge aecf3d8...

@bors
Copy link
Collaborator

bors commented May 1, 2015

@bors bors merged commit 30a5448 into rust-lang:master May 1, 2015
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants