Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Xamarin.Android.Build.Tasks] delay ToJniName calls in ManifestDocume…
…nt (#7653) Reviewing `dotnet trace` output for a `dotnet new maui` app: dotnet trace collect --format speedscope -- .\bin\Release\dotnet\dotnet.exe build -bl --no-restore foo.csproj 8.6% of the time in `<GenerateJavaStubs/>` is spent in: 93.81ms xamarin.android.build.tasks!Xamarin.Android.Tasks.ManifestDocument.Merge(...) Drilling down further, a lot of time is spent in: 26.91ms java.interop.tools.javacallablewrappers!Java.Interop.Tools.TypeNameMappings.JavaNativeTypeManager.ToJniName(...) 4.03ms java.interop.tools.javacallablewrappers!Java.Interop.Tools.TypeNameMappings.JavaNativeTypeManager.ToCompatJniName(...) It looks like we call this code for *every* Java.Lang.Object subclass: var name = JavaNativeTypeManager.ToJniName (t, cache).Replace ('/', '.'); var compatName = JavaNativeTypeManager.ToCompatJniName (t, cache).Replace ('/', '.'); if (((string) app.Attribute (attName)) == compatName) { app.SetAttributeValue (attName, name); } It looks like this code was originally here to solve a problem with `Android.App.Application` classes that are missing an `[Application]` attribute: xamarin/monodroid@2a668b7 To improve this: 1. First check if we are a `Android.App.Application`, apply the above fixup and `continue`. 2. Find out if we are other types of interesting subclasses, where a `generator` is needed. `continue` otherwise. 3. Lastly, compute `name` & `compatName`. We are no longer doing this work for every type. After these changes, I instead get: 72.84ms xamarin.android.build.tasks!Xamarin.Android.Tasks.ManifestDocument.Merge(...) This saves about ~21ms on incremental builds of `dotnet new maui` projects.
- Loading branch information