Discuss disabling Dynamic PGO by default for CoreCLR Android apps while preserving developer opt-in #13039

Android framework version

net11.0-android (Preview)

Affected platform version

Measured with the installed .NET 11 RC2 stack:

• .NET SDK: 11.0.100-rc.2.26475.136
• CoreCLR runtime: 11.0.0-rc.2.26475.136
• Android workload: 37.2.0-rc.2.84
• Microsoft.Maui.Controls: 11.0.0-rc.2.26475.3
• Sample-content template: Microsoft.Maui.Templates.net11 11.0.0-rc.1.26451.6 (the manually installed template selected by dotnet new)
• Device: Samsung Galaxy A16 (SM-A165F), Android 16, arm64

These measurements use the installed workload, not a locally built SDK from dotnet/android main.

Description

Should .NET for Android override the CoreCLR default and disable Dynamic PGO by default, while allowing developers to enable it explicitly with <TieredPGO>true</TieredPGO>?

Where the current default comes from

Dynamic PGO is inherited from .NET CoreCLR, rather than explicitly enabled by the Android SDK. Neither the checked-out Android product targets (revision 0205e8caae9daca2b587eef49592c8253485f751) nor the installed Android/MAUI SDK targets set TieredPGO or TieredCompilation. Both properties are empty when evaluating the sample without an override.

The common .NET SDK emits System.Runtime.TieredPGO into runtime configuration only when $(TieredPGO) is nonempty. With the entry omitted, CoreCLR chooses its own default. A separate on-device JIT diagnostic confirmed the exact shipped runtime produces an instrumented tier followed by code optimized using Dynamic PGO when the property is omitted. With TieredPGO=false, it produces uninstrumented Tier1 code with No PGO data.

Reference: Microsoft Learn: profile-guided optimization configuration. This discussion concerns CoreCLR Dynamic PGO, not Mono profiled AOT, NativeAOT, or static ReadyToRun/MIBC PGO.

Measured startup effect

A matched A/B experiment on the MAUI sample-content app found a small but consistent startup benefit from disabling Dynamic PGO:

There were 30 measured cold-process launches per variant, in 10 matched installation pairs. Disabled was faster in all 10 pairs. The paired bootstrap 95% confidence interval for the dashboard improvement is 24.43–45.47 ms (20,000 resamples of installation pairs, seed 20261008; individual launches were not treated as independent resampling units).

Both variants used Release, trimming, CoreCLR, arm64, and the default MAUI partial ReadyToRun compilation. Tiered compilation remained at its enabled runtime default. APK verification showed byte-identical managed assembly stores, CoreCLR/runtime libraries, DEX, and resources; only the generated native runtime configuration and APK signatures differed. The runtime configurations differed only in System.Runtime.TieredPGO.

Discussion / possible policy

• Consider an Android-specific TieredPGO=false default for CoreCLR applications only when the developer has not specified the property. Preserve explicit true and false; reuse the existing .NET property rather than introducing a new Android-specific switch.
• Keep tiered compilation and static ReadyToRun PGO separate from this decision. Neither was disabled in the experiment.
• Decide whether the policy belongs in the Android SDK or a MAUI-specific layer, and whether it should be limited to particular build configurations.
• Before changing the default, measure sustained throughput, longer UI interactions, CPU/energy/memory, additional apps, and additional devices. Dynamic PGO may improve these workloads even though it slightly slowed this startup scenario.

The experiment supports investigating a startup-oriented default, not concluding that Dynamic PGO is universally detrimental. No product default has been changed.

Steps to Reproduce

1. Use the versions above and generate dotnet new maui --sample-content -n PgoStartupSample --no-restore. Target Android only and use a dedicated package ID. Pin Microsoft.Extensions.Logging.Debug to 11.0.0-rc.2.26475.136 rather than leaving its template floating version.

2. Add identical readiness instrumentation to both variants: after MainPageModel.Appearing completes its initial InitData, sets _dataLoaded, and completes the subsequent Refresh, register a one-shot ViewTreeObserver.IOnDrawListener on the activity decor view. On the next draw, post a callback that removes the listener and calls Activity.ReportFullyDrawn(). This measures data-loaded dashboard draw rather than only splash/first-window display. The two startup refreshes are preserved.

3. Publish and preserve the enabled APK, then publish and preserve the disabled APK:

   dotnet publish PgoStartupSample.csproj -c Release -f net11.0-android -r android-arm64 -p:TieredPGO=true -p:AndroidPackageFormats=apk -bl:pgo-on.binlog
   dotnet publish PgoStartupSample.csproj -c Release -f net11.0-android -r android-arm64 -p:TieredPGO=false -p:AndroidPackageFormats=apk -bl:pgo-off.binlog

   Both commands passed. Set AndroidSdkDirectory and JavaSdkDirectory as appropriate for the host. Verify the generated runtime configuration values and compare uncompressed APK payloads; the measured managed/runtime payloads were identical.

4. Seed the app database once, retaining identical preferences and database across replacement installs. Use adb install -r --no-streaming to switch variants with the same package ID. After each install, run adb shell cmd package compile -m speed -f <package> to keep Java ART compilation mode fixed.

5. Run 10 matched installation pairs, five enabled-first and five disabled-first, shuffled with seed 20261008. After each install, discard two launches and measure three. Before every launch, force-stop the package, confirm there is no live PID, wait one second, then run adb shell am start -W -n <component>. Require LaunchState: COLD, successful launch, and a Fully drawn/readiness report from the new process. Allow three seconds cooldown between launches.

6. Capture first-display TotalTime and ActivityTaskManager Fully drawn duration. All 60 measured launches passed, with unique processes and no crashes/timeouts. All 20 per-install thermal checks reported thermal status 0; battery temperature was 24.7–25.3 °C. The phone was USB-powered with a full battery and its existing animation scales were zero; no global device settings were changed.

7. Analyze the paired block means. Dashboard disabled - enabled differences in milliseconds were:

   -35.67, -3.00, -47.67, -20.33, -39.67,
   -52.33, -37.33, -45.67, -13.67, -59.33
   

Scope/limitations: these are force-stopped process-cold launches with seeded app data and warm filesystem caches, not first-install database seeding or reboot/cache-cold measurements. Only one device and stack were measured. Separate JIT diagnostic builds and post-experiment visual checks were excluded from timing samples. No sustained-throughput, energy, or memory conclusions are available.

Did you find any workaround?

Developers can already disable Dynamic PGO using the existing .NET property:

<PropertyGroup>
  <TieredPGO>false</TieredPGO>
</PropertyGroup>

If we adopt a disabled Android default, developers should retain the explicit opt-in:

<PropertyGroup>
  <TieredPGO>true</TieredPGO>
</PropertyGroup>

Relevant log output

Separate diagnostics on the same shipped runtime, with no TieredPGO override:

Runtime=11.0.0; explicit_pgo=False; value=False
; Assembly listing for method PgoStartupSample.MainActivity:DynamicPgoProbe(int):int (Instrumented Tier1)
; Instrumented Tier1 code
; Assembly listing for method PgoStartupSample.MainActivity:DynamicPgoProbe(int):int (Tier1)
; Tier1 code
; optimized using Dynamic PGO

explicit_pgo=False means AppContext.TryGetSwitch found no explicit configuration entry; it does not mean the native runtime default is disabled. JIT output establishes the actual behavior.

With TieredPGO=false:

Runtime=11.0.0; explicit_pgo=True; value=False
; Assembly listing for method PgoStartupSample.MainActivity:DynamicPgoProbe(int):int (Tier1)
; Tier1 code
; No PGO data

Both diagnostic builds and the final default-versus-disabled JIT verification passed. The JIT output stream was flushed and only newly appended output from each process was inspected, avoiding stale disassembly from earlier launches.