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

use more Rc in the part of resolver that gets cloned a lot 2 #5302

Merged
merged 2 commits into from
Apr 6, 2018

Conversation

Eh2406
Copy link
Contributor

@Eh2406 Eh2406 commented Apr 5, 2018

This is the same idea as #5118, I was looking at a profile and noted that ~5% of our time was sent dropping HashMap<PackageId, HashSet<InternedString>>. A quick rg and I found the culprit, we are cloning the set of features for every new Context. With some Rc we are now just cloning for each time we insert.

To benchmark I commented out line

has_past_conflicting_dep = true;

the smallest change to get #4810 (comment) not to solve instantly.
Before 17000000 ticks, 90s, 188.889 ticks/ms
After 17000000 ticks, 73s, 232.877 ticks/ms

.or_insert_with(HashSet::new);
.or_insert_with(|| Rc::new(HashSet::new()));

let mut inner: HashSet<_> = (**set).clone();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this perhaps use Rc::make_mut? That way we could have a fast path as well for when the Context hasn't been cloned?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an algorithmic improvement, I think HashSet.clone() is now O(# activated * ticks) and this pr bings it to O(# activated).

I can experiment with that, here and for #5118, but I suspect it will be rare. Not only does the context need not to be cloned, but it needs not to have been cloned since last time that this package was added. Would you like me to do that expremint in this PR or in a follow up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it in this PR as it made the diff much smaller. New performance numbers on the way.

@Eh2406
Copy link
Contributor Author

Eh2406 commented Apr 6, 2018

New numbers after using Rc::make_mut are, within the uncertainty of the measurement, the same. But the code is cleaner, and it may be faster for some other workloads.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Apr 6, 2018

📌 Commit 04fbc5f has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Apr 6, 2018

⌛ Testing commit 04fbc5f with merge d83f113...

bors added a commit that referenced this pull request Apr 6, 2018
use more Rc in the part of resolver that gets cloned a lot 2

This is the same idea as #5118, I was looking at a profile and noted that ~5% of our time was sent dropping `HashMap<PackageId, HashSet<InternedString>>`. A quick rg and I found the culprit, we are cloning the set of features for every new `Context`. With some Rc we are now just cloning for each time we insert.

To benchmark I commented out line https://github.com/rust-lang/cargo/blob/b9aa315158fe4d8d63672a49200401922ef7385d/src/cargo/core/resolver/mod.rs#L453
the smallest change to get #4810 (comment) not to solve instantly.
Before 17000000 ticks, 90s, 188.889 ticks/ms
After 17000000 ticks, 73s, 232.877 ticks/ms
@bors
Copy link
Contributor

bors commented Apr 6, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing d83f113 to master...

@bors bors merged commit 04fbc5f into rust-lang:master Apr 6, 2018
@Eh2406 Eh2406 deleted the MoreRc branch May 10, 2018 17:47
@ehuss ehuss added this to the 1.27.0 milestone Feb 6, 2022
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.

5 participants