-
Notifications
You must be signed in to change notification settings - Fork 52
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Java.Interop.Tools.JavaCallableWrappers] use IMetadataResolver more (#…
…1069) Context: b81cfbb Reviewing code in `JavaCallableWrapperGenerator`, I found codepaths where we weren't caching `TypeReference.Resolve()` calls *at all*, e.g. `JavaNativeTypeManager.GetPrimitiveClass(TypeDefinition)`. We thus appear to be calling `TypeReference.Resolve()` potentially on the same types. For example, `dotnet trace` output of an incremental build of a `dotnet new maui` project: 41.65ms xamarin.android.cecil!Mono.Cecil.TypeReference.Resolve() It appears that, in trying to make our maintenance lives easier by preserving backward API compatibility with callers that couldn't provide a `TypeDefinitionCache` or `IMetadataResolver` instance -- by providing method overloads which took e.g. `IMetadataResolver? resolver` parameters which could be `null` -- we made our optimization and performance lives *harder*, because not all codepaths which needed to use caching *were* using caching, as they were overlooked. As the `Java.Interop.Tools.*` assemblies are internal API, introduce an *API break* while preserving *ABI*: `IMetadataResolver` is now required. Thus, previous/current "compatibility methods" which allow *not* providing an `IMetadataResolver` instance such as: // old and busted partial class TypeDefinitionRocks { [Obsolete ("Use the TypeDefinitionCache overload for better performance.")] public static TypeDefinition? GetBaseType (this TypeDefinition type) => GetBaseType (type, resolver: null); } will now become *errors* to use: // new hawtness partial class TypeDefinitionRocks { [Obsolete ("Use the TypeDefinitionCache overload for better performance.", error:true)] public static TypeDefinition? GetBaseType (this TypeDefinition type) => throw new NotSupportedException (); } This allows the C# compiler to help us audit our codebase, ensuring that *all* codepaths which call `TypeReference.Resolve()` instead use `IMetadataResolver.Resolve()`, including: * `JavaCallableWrapperGenerator.GetAnnotationsString()` * `JavaCallableWrapperGenerator.WriteAnnotations()` * `JavaNativeTypeManager.GetPrimitiveClass()` Requiring caching results in: 23.89ms xamarin.android.cecil!Mono.Cecil.TypeReference.Resolve() Additionally, I updated two places to use plain `foreach` loops instead of using System.Linq. * Before: 1.03s xamarin.android.build.tasks!Xamarin.Android.Tasks.GenerateJavaStubs.RunTask() * After: 944.48ms xamarin.android.build.tasks!Xamarin.Android.Tasks.GenerateJavaStubs.RunTask() I think this likely saves about ~50ms off incremental builds of a `dotnet new maui` project.
- Loading branch information
1 parent
5c5dc08
commit cf80deb
Showing
8 changed files
with
185 additions
and
207 deletions.
There are no files selected for viewing
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
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
Oops, something went wrong.