TypeMapLazyDictionary is slow in android apps - Can we preconstruct the dictionary?

[jtschuster]

In the Android prototype using TypeMapAttributes for the type mapping system, an assembly that is about 13mb (pre-trimming) is generated that includes all the generated types and TypeMapAttributes. Startup is over 2 seconds, up from ~200 ms in mono, likely due to building the typemap at startup. More perf measurements are planned this week to confirm the issue, but this is too slow, and the slowdown grows with size of the app. The previous approach in mono is close to constant speed relative to app size.

ILLink has a whole-program view like ilc, and could produce a hard-coded dictionary like ilc and the previous typemapping solution for mono.

Proposal:
We frontload the creation of an IDictionary<string, DelayedType> / IDictionary<VersionResilientTypeHash, DelayedType>, and load the type at runtime. This would remove the overhead of parsing the TypeMapAttributes at startup, and only loading would be necessary. The exact format and implementation of the dictionary is up for debate. It could be in a binary blob similar to ilc, or in IL, or something else.

Alternatives

• A lookup method that is a switch statement from string to typeofs in IL would be fast, but requires references to the assemblies that contain the types. Adding these references to CoreLib doesn't feel right.
• Split the TypeMapAttributes into their own assemblies. It could be that loading such a large assembly slows the startup significantly. However, startup time will still grow with the size of the application, and it's not clear if this will move the needle much.

cc @dotnet/illink @simonrozsival @AaronRobinsonMSFT

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[AaronRobinsonMSFT]

More perf measurements are planned this week to confirm the issue, but this is too slow, and the slowdown grows with size of the app.

Please share these details when you get them.

This would remove the overhead of parsing the TypeMapAttributes at startup

We should be able to see this cost in a trace and be able to determine if that is indeed the bottleneck.

[jtschuster]

I spoke with @jkoritzinsky who mentioned it would be possible to use crossgen2 for the preinitialization of the TypeMap dictionary in the same format as ILC, rather than doing something in ILLink. This seems like a better idea than adding more to ILLink.

[AaronRobinsonMSFT]

who mentioned it would be possible to use crossgen2 for the preinitialization of the TypeMap dictionary in the same format as ILC

Yes. Using crossgen2 for pre generation is going to be the recommended path. Let's see the bottlenecks first though. Imposing a crossgen2 dependency on non release scenarios is going to be a second best approach.

[simonrozsival]

Please share these details when you get them.

I'll definitely run a few tests and share the data I collect.

it would be possible to use crossgen2 for the preinitialization of the TypeMap dictionary in the same format as ILC, rather than doing something in ILLink

This sounds great!

Imposing a crossgen2 dependency on non release scenarios is going to be a second best approach.

We want to R2R the Debug assemblies of the .NET Android + MAUI SDKs (most notably Mono.Android.dll) to speed up the runtime perf during inner dev loop. If we split the types into two "type universes" (one for built-in bindings (~8000) and one for app + third party library bindings (<100 for most apps)) then the large built-in one could be precompiled through crossgen2 and the small one could be easily lazy loaded and we wouldn't need ILLink or crossgen2 in the inner dev loop (also it might be much easier to make this setup work with hot reload).