You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context: dotnet/android#4268
I was profiling builds with the Mono profiler and noticed:
Method call summary
Total(ms) Self(ms) Calls Method name
70862 97 89713 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)
Almost 90K calls to `DirectoryAssemblyResolver.Resolve()`?!
Where is that coming from???
61422 calls from:
Java.Interop.Tools.Cecil.TypeDefinitionRocks/<GetTypeAndBaseTypes>d__1:MoveNext ()
Java.Interop.Tools.Cecil.TypeDefinitionRocks:GetBaseType (Mono.Cecil.TypeDefinition)
Mono.Cecil.TypeReference:Resolve ()
Mono.Cecil.ModuleDefinition:Resolve (Mono.Cecil.TypeReference)
Mono.Cecil.MetadataResolver:Resolve (Mono.Cecil.TypeReference)
Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference)
OK, this jogged my memory. @StephaneDelcroix had mentioned one of
the big wins for the `<XamlC/>` task within Xamarin.Forms was to
cache any time `TypeReference.Resolve()` was called:
https://github.com/xamarin/Xamarin.Forms/blob/1b9c22b4b9b1c1354a3a5c35ad445a2738c6f6c3/Xamarin.Forms.Build.Tasks/TypeReferenceExtensions.cs#L437-L443
`<XamlC/>` was able to use `static` here, because it's using a
feature of MSBuild to run in a separate `AppDomain`:
https://github.com/xamarin/Xamarin.Forms/blob/1b9c22b4b9b1c1354a3a5c35ad445a2738c6f6c3/Xamarin.Forms.Build.Tasks/XamlTask.cs#L20-L21
However, I think we can simply add a new `TypeDefinitionCache` class
that would allow callers to control the caching strategy. Callers
will need to control the scope of the `TypeDefinitionCache` so it
matches any `DirectoryAssemblyResolver` being used. Right now most
Xamarin.Android builds will open assemblies with Mono.Cecil twice:
once for `<GenerateJavaStubs/>` and once for the linker.
We can add caching in an API-compatible way:
[Obsolete ("Use the TypeDefinitionCache overload for better performance.")]
public static TypeDefinition GetBaseType (this TypeDefinition type) =>
GetBaseType (type, cache: null);
public static TypeDefinition GetBaseType (this TypeDefinition type, TypeDefinitionCache cache)
{
if (bt == null)
return null;
if (cache != null)
return cache.Resolve (bt);
return bt.Resolve ();
}
We just need to ensure `cache: null` is valid. I took this approach
for any `public` APIs and made any `private` or `internal` APIs
*require* a `TypeDefinitionCache`.
I fixed every instance where `[Obsolete]` would cause a warning here
in Java.Interop. We'll probably see a small improvement within
`generator` and `jnimarshalmethod-gen`.
Downstream in xamarin-android, in dotnet/android#4268 I
fixed all the `[Obsolete]` warnings that were present in
`<GenerateJavaStubs/>`. I can make more changes for the linker in
a future PR.
~~ Results ~~
The reduced calls to `DirectoryAssemblyResolver.Resolve()`:
* Before:
Method call summary
Total(ms) Self(ms) Calls Method name
70862 97 89713 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)
* After:
Method call summary
Total(ms) Self(ms) Calls Method name
68830 35 26315 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)
~63,398 less calls.
In a build of the Xamarin.Forms integration project on macOS / Mono:
* Before:
1365 ms GenerateJavaStubs 1 calls
* After:
862 ms GenerateJavaStubs 1 calls
It is almost a 40% improvement, around ~500ms better.
0 commit comments