Change how runtime dependencies are included in new dependency resolver #6211
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jeffkl
commented
Jan 7, 2025
test/NuGet.Core.FuncTests/NuGet.Commands.FuncTest/RestoreCommandTests.cs
Show resolved
Hide resolved
jeffkl
changed the title
nkolev92
reviewed
Jan 7, 2025
src/NuGet.Core/NuGet.Commands/RestoreCommand/DependencyGraphResolver.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Core/NuGet.Commands/RestoreCommand/DependencyGraphResolver.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.FuncTests/NuGet.Commands.FuncTest/RestoreCommand_AlgorithmEquivalencyTests.cs
Outdated
Show resolved
Hide resolved
jeffkl
force-pushed
the
dev-jeffkl-fix-runtimedependnecies2
branch
from
72022c7 to
2aea2e1
Compare
jeffkl
added
the
Merge next release
nkolev92
approved these changes
Jan 8, 2025
| /// <summary> | ||
| /// Represents a cache key for storing <see cref="ResolvedLibraryEntry" /> items in a dictionary with a unique <see cref="FrameworkRuntimePair" /> and <see cref="LibraryRangeIndex" />. | ||
| /// </summary> | ||
| private readonly struct ResolvedLibraryEntryCacheKey : IEquatable<ResolvedLibraryEntryCacheKey> |
There was a problem hiding this comment.
Is there an added cost from the constant hashing of FrameworkRuntimePair?
I see that the type is immutable, so they may be an opportunity to improve the performance there by caching the hash.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug
Fixes: NuGet/Home#13800
Description
This updates how runtime dependencies are handled in the new resolver. Currently, the resolver loops through each pair of target framework and runtime identifier, calling
ResolverUtility.FindLibraryEntryAsync()for each dependency. This results in the code callingFindLibraryEntryAsync()multiple times for the same dependency for each runtime of the same framework. The legacy resolver caches calls toFindLibraryEntryAsync()for each target framework, regardless of the runtime identifier. Runtime specific packages generally have unique IDs so it works.The data returned by
FindLibraryEntryAsync()includes aRemoteMatchwhich specifies the dependencies according to a project or.nuspec. When the resolver is resolving a graph for a runtime specific graph, it mutates the list by augmenting any runtime packages specified inruntime.json. However, when lock files are in use, the resolver needs to ensure that its callingFindLibraryEntryAsync()when a runtime is specified, otherwise in locked mode it cannot find the packages in thepackages.lock.json.This change introduces a second caching layer, which is target framework/runtime identifier and dependency ID specific. Calls to
FindLibraryEntryCachedAsync()remain cached by target framework and dependency ID. Then for each runtime identifier, the runtime dependencies are merged into the list of dependencies and that list is cached. This ensures that each call toFindLibraryEntryAsync()only happens once per target framework/dependency but that runtime specific graphs still look up dependencies in lock files correctly.Its a potential breaking change that the new resolver will be enabled by default if lock files are being used. We'll need to discuss whether or not this is okay.
PR Checklist