Repository navigation
[CoreCLR] Enable cached ReadyToRun for Android Debug builds #12117
Description
Activity
- linked a pull request that will close this issueEnable cached ReadyToRun for CoreCLR Android Debug builds #12118
on Jul 15, 2026 Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including System.Private.CoreLib.dll
Can we do this ahead of time? And the image is just inside the runtime pack?
If I look at System.Private.CoreLib.dll on my Windows machine, it has a win-x64 R2R image inside already:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\<version>\System.Private.CoreLib.dllIf I were to set this up for Mono.Android.dll or Java.Interop.dll, I would also do it ahead of time inside the runtime pack.
Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including System.Private.CoreLib.dll
Can we do this ahead of time? And the image is just inside the runtime pack?
If I look at System.Private.CoreLib.dll on my Windows machine, it has a win-x64 R2R image inside already:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\<version>\System.Private.CoreLib.dllIf I were to set this up for Mono.Android.dll or Java.Interop.dll, I would also do it ahead of time inside the runtime pack.
We can generate them ahead of time, but those images only work with the full untrimmed assemblies. Do we run trimming on these assemblies in Debug?
Do we run trimming on these assemblies in Debug?
No, Android doesn't have a need to trim in debug mode.
Someone, could turn on
PublishTrimmed=truein debug mode, but I wouldn't recommend as it would make your incremental builds slower.I measured this end to end on net11 CoreCLR for android-arm64, comparing the current Debug default against the framework-R2R approach in #12118, on both a hello-world app and a MAUI app, which R2Rs the runtime pack assemblies including Mono.Android.dll and excludes user code.
Hello-world, no measurable difference. Startup is dominated by runtime init rather than managed JIT, so R2R does not improve it. MAUI framework R2R is consistently about 100ms or 3% faster than JIT and about 6MB bigger app with a first clean crossgen2 pass about 20s, with incremental builds reusing the crossgen cache.
Based on this, trimming in Debug regresses the inner dev loop, and adding R2R back on trimmed assemblies is not a good fit here. It could make sense to ship pre-compiled Mono.Android.dll or Java.Interop.dll to gain 3% faster startup (not complete inner dev loop) at the cost of a 6 MB larger app. Worth confirming with few customer apps before dedicating the effort.
Summary
CoreCLR Android Debug builds currently use JIT compilation for all assemblies. Enable cached ReadyToRun compilation for stable framework and SDK assemblies, including
System.Private.CoreLib.dll, to improve startup performance while keeping user assemblies as IL for normal debugging and incremental development.Android Debug application size is not a primary constraint. The ReadyToRun output should be generated once for each RID and stable framework input set, then reused by subsequent builds. Changes limited to user assemblies must not rerun crossgen2.
This issue covers non-profiled Debug ReadyToRun.
Tasks
System.Private.CoreLib.dll