ResolveAssemblyReference CPU optimizations (redo) #9044
Merged
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.
#8916 broke some .NET Framework scenarios and was reverted. This PR is a redo of the change with the bug fixed. It turned out that the destination of the optimized
CopyMetadataTo
may be a transparent proxy, typically aTaskItem
object living in another appdomain, which does not work well with Linq. The fix and the test coverage are in their own commits.Context
Low-hanging fruit is showing in RAR performance profiles.
Changes Made
Avoided constructing
AssemblyName
on a hot path as the constructor makes expensive Fusion calls on .NET Framework. The problematic code was introduced in [RAR] Don't do I/O on SDK-provided references #8688.Added a metadata bulk-set operation to the internal
IMetadataContainer
interface. CallingSetMetadata
for more than a couple of metadata is slow ifImmutableDictionary
is used as its backing storage. RAR is heavy on metadata manipulation and switching to the new operation saves about 10% of RAR run-time when building OrchardCore.Testing
Existing and new unit tests. Measured the perf impact by building OC.