Part of #10788
The implementation of the typemap lookup data structure in .NET 10 in CoreCLR scans assembly-level attributes in the type map assembly and builds a Dictionary<string, DelayedType>. This can be noticeably slow for large typemaps, especially in Debug builds, where there are all the types from Mono.Android (~8000) and from all the other libraries and the app itself. In Native AOT, the lookup data structure is pre-compiled and ready to use at runtime without costly initialization. The Runtime team is looking into pre-compiling the same intrinsic data structure through crossgen2 (R2R).
We could save the developers a few seconds during each Debug build and several hundreds of millisecodns every Debug build startup if we split the typemap in two: one pre-generated in the Mono.Android during SDK build time that could be pre-compiled through crossgen2 once we implement #10760. During prototyping, assembly scanning and IL + Java codegen took roughly 6s on MacBook M1 of which 5s was spent just scanning Mono.Android. The build time gain would be even more pronounced on lower end dev machines.
Goal: There is no need to do assembly scanning for the huge Mono.Android.dll and there's optimization opportunity
Mono.Android is scanned and code for its typemap is generated into a Mono.Android.TrimmableTypeMap.dll (with its own internal "type mapping universe" type) + the java code for JCWs is precompiled in mono-android-trimmable-typemap-jcw.jar.
Runtime code will need to be adjusted to use the Mono.Android and app-specific typemaps together
Part of #10788
The implementation of the typemap lookup data structure in .NET 10 in CoreCLR scans assembly-level attributes in the type map assembly and builds a
Dictionary<string, DelayedType>. This can be noticeably slow for large typemaps, especially in Debug builds, where there are all the types from Mono.Android (~8000) and from all the other libraries and the app itself. In Native AOT, the lookup data structure is pre-compiled and ready to use at runtime without costly initialization. The Runtime team is looking into pre-compiling the same intrinsic data structure through crossgen2 (R2R).We could save the developers a few seconds during each Debug build and several hundreds of millisecodns every Debug build startup if we split the typemap in two: one pre-generated in the Mono.Android during SDK build time that could be pre-compiled through crossgen2 once we implement #10760. During prototyping, assembly scanning and IL + Java codegen took roughly 6s on MacBook M1 of which 5s was spent just scanning Mono.Android. The build time gain would be even more pronounced on lower end dev machines.
Goal: There is no need to do assembly scanning for the huge Mono.Android.dll and there's optimization opportunity
Mono.Android is scanned and code for its typemap is generated into a
Mono.Android.TrimmableTypeMap.dll(with its own internal "type mapping universe" type) + the java code for JCWs is precompiled inmono-android-trimmable-typemap-jcw.jar.Runtime code will need to be adjusted to use the Mono.Android and app-specific typemaps together