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

Reduce allocations again in ComputeReverseReferencesMap #76417

Merged

Conversation

ToddGrun
Copy link
Contributor

Speedometer results from the last PR didn't improve allocations in the ProjectDependencyGraph as much as I had hoped. This PR instead changes ComputeReverseReferencesMap to use pooled data structures and ImmutableHashSet.Builder to build up it's final result.

The speedometer test is still showing about 100 MB of allocations in this method during typing, my hope is that this should cut that in about half. Will create a test insertion for validation.

*** allocations that are being targeted by this PR ***
image

Speedometer results from the last PR didn't improve allocations in the ProjectDependencyGraph as much as I had hoped. This PR instead changes ComputeReverseReferencesMap to use pooled data structures and ImmutableHashSet.Builder to build up it's final result.

The speedometer test is still showing about 100 MB of allocations in this method during typing, my hope is that this should cut that in about half. Will create a test insertion for validation.
@ToddGrun ToddGrun requested a review from a team as a code owner December 13, 2024 13:29
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Dec 13, 2024
@ToddGrun
Copy link
Contributor Author

ToddGrun commented Dec 13, 2024

2) Increase pool size from 128 to 256 as that's not an uncommon number of projects
return KeyValuePairUtil.Create(kvp.Key, reverseReferencesForProject);
})
.ToImmutableDictionary();
return reverseReferencesMap.ToImmutableDictionary();
Copy link
Member

Choose a reason for hiding this comment

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

poooled dict, to immutable dict? shouldn't this just be an ImmutableDictBuilder?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It could be, but the builder is a class itself, so this avoids that allocation. I can switch to that though if you prefer.

Copy link
Member

Choose a reason for hiding this comment

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

teh main concern here is that to go from Dict to ImmutableDict you are rehashing everything.

Note: you could pool the ImmutableDictBuilder if you want to save that allocation.

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'll just switch to an ImmutableDictBuilder here and see what the test insertion says.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Insertions says the allocation of the dictionary builder vs using a pooled dictionary doesn't show up, so we'll just go with this approach

@ToddGrun
Copy link
Contributor Author

@ToddGrun ToddGrun merged commit 5a98024 into dotnet:main Dec 14, 2024
25 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Dec 14, 2024
@dibarbet dibarbet modified the milestones: Next, 17.13 P3 Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead VSCode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants