-
Notifications
You must be signed in to change notification settings - Fork 694
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
Improved performance of calculation of PrivateAssets for transitively pinned centrally managed dependencies #4954
Improved performance of calculation of PrivateAssets for transitively pinned centrally managed dependencies #4954
Conversation
…ansitiveDependencies
…rcink-20221128-assets_flow_for_project_and_packages
…ess whether the parent is a project or a package
…ink-20221123-CentralTransitiveDependencies # Conflicts: # src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 90 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
@marcin-krystianc what's the status of this? I'd like to get this in the next release if there's a large performance increase. |
I needed previous PRs to be merged. Now I can resolve remaining conflicts and fine tune it. It should be ready to review soon. |
…alTransitiveDependencies # Conflicts: # src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs # test/NuGet.Core.Tests/NuGet.Commands.Test/IncludeTypeTests.cs # test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests.cs
@jeffkl It is ready for a review. I've tested the restore time using the test scenario from the NuGet/Home#12269 and now the restore time is more or less the same as it was for 6.0.400. |
@@ -517,6 +517,8 @@ private IEnumerable<LibraryDependency> GetLibraryDependenciesForCentralTransitiv | |||
{ | |||
foreach (GraphNode<RemoteResolveResult> rootNode in targetGraph.Graphs) | |||
{ | |||
var dependencyDictionary = rootNode.Item.Data.Dependencies.ToDictionary(x => x.Name, x => x, StringComparer.OrdinalIgnoreCase); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there cases where this dictionary won't end up being used? On line 525 nodes can be skipped, so perhaps don't initialize this dictionary until its needed on line 538?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it is possible that the dictionary will not be eventually used but it is not very likely scenario. I don't have strong opinion here..
} | ||
|
||
suppressParent &= parentDependency.SuppressParent; | ||
var dependency = dependencyDictionary[dependencyNode.Key.Name]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use explicit type instead of var
please.
{ | ||
yield return outerNode; | ||
// It's what we are looking for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please clarify this comment that the node is a parent
03dae82
to
6e4e758
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution. I ran the changes under the debugger and everything seems to still work. Would it be possible to get some benchmarks just so we know how much faster this is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this fix.
A few suggestions to reduce allocations.
src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs
Outdated
Show resolved
Hide resolved
Sure, just got some measurements for https://github.com/marcin-krystianc/TestSolutions/tree/master/LargeAppWithPrivatePackagesCentralisedNGBVRemoved on my dev laptop (multiple runs, but posting the best result only):
I see that there is still some noticeable difference when compared to 6.0.400, but I think it is justified by the extra work needed to correctly calculate effective PrivateAssets value for central transitive dependencies. |
@marcin-krystianc something broke with our PR build pipeline but is now fixed, can you please rebase your change onto latest |
@@ -525,23 +530,21 @@ private IEnumerable<LibraryDependency> GetLibraryDependenciesForCentralTransitiv | |||
continue; | |||
} | |||
|
|||
if (dependencyDictionary == null) | |||
{ | |||
dependencyDictionary = rootNode.Item.Data.Dependencies.ToDictionary(x => x.Name, x => x, StringComparer.OrdinalIgnoreCase); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that GraphNode doesn't implement hashcode made me a bit nervous, but I think it's ok in this case, as the data itself will never be duplicated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, not sure what was your concern really. Was it about HashSet<GraphNode<T>>
for visited nodes? I think it is ok that it doesn't have proper equality comparer. We care about not visiting the same graph node twice, but it is ok when there are multiple nodes representing same project or package.
…alTransitiveDependencies
Done |
@marcin-krystianc Nice work on this. Looking our allocation telemetry, I can see this addressed the majority of the issues on this path. |
Bug
Fixes: NuGet/Home#12269
Regression? Last working version: 6.0.400
Description
Existing code enumerated parent nodes in an inefficient fashion, it could yield the same node many times. Another performance issue was a linear scan to get the dependency node for the given parent node.
It is being fixed by:
PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation