Performance regression upgrading from 10.0.100 -> 10.0.300

[ekalchev]

Describe the bug

We have multiple WPF desktop apps running on .NET 10 self contained, compiled with ReadyToRun (R2R) and distributed as MSIX packages.

We run automated performance-monitoring tests that measure app startup time for every build. After upgrading our SDK to 10.0.300, these tests detected a startup-time regression of roughly 100 ms (~10%) across our apps. In the chart below, each colored line is a different application:

Some details on what we observed:

• Reverting to 10.0.100 restored the faster startup times — the regression tracks the SDK/runtime version, not our code.
• I then tried the latest 10.0.301, and the startup times jumped again, so the regression is still present in the newest servicing release.
• We have not yet profiled the apps, so I can't point to exactly where the extra time is spent — but it is consistently ~100 ms, which is ~10% of our startup time.

This really hurts us, because we invest a huge amount of effort into reducing the already-slow startup of .NET WPF apps, and this upgrade wiped out a meaningful chunk of those gains. I'm hoping this gets attention.

Minimal reproduction

I built a minimal reproduction to quantify this. Two trivial WPF apps (App1 = empty window, App2 = window with menu/toolbar/DataGrid), published self-contained + ReadyToRun (win-x64) so the runtime is pinned to the SDK rather than to whatever shared runtime is installed.

Measurement: each app records DateTime.Now − Process.StartTime at its ContentRendered event (first rendered frame) and appends it to a CSV. 30 measured launches per configuration, 3 warmups discarded, and the four configs are interleaved (100/300/100/300…) so any background/thermal drift hits all of them equally. Medians are used to reject outliers.

The only variable changed is the SDK, which determines the bundled runtime:

Bundled runtime per SDK:

SDK	Bundled WPF / CLR
10.0.100	PresentationCore 10.0.0-rtm + coreclr 10.0.0
10.0.300	PresentationCore 10.0.8-servicing + coreclr 10.0.8

Startup time — median of 30 runs (ms):

App	10.0.100	10.0.300	Delta
App1 (empty window)	538.9	589.7	+50.8 (+9.4%)
App2 (menu/toolbar/DataGrid)	626.3	716.7	+90.4 (+14.4%)

Full stats — median / mean / min / max (ms):

App	SDK	Median	Mean	Min	Max
App1	10.0.100	538.9	549.2	518.9	611.0
App1	10.0.300	589.7	593.0	567.0	643.1
App2	10.0.100	626.3	633.5	592.7	695.9
App2	10.0.300	716.7	718.9	671.1	817.2

Key takeaway: the regression reproduces on an empty WPF window (App1), so this is in the framework/runtime, not application code. Moving from the 10.0.0 RTM runtime to the 10.0.8 servicing runtime costs ~50–90 ms (9–14%) of startup, which matches the ~100 ms / ~10% regression I originally reported across our production apps. The heavier app pays more in absolute terms.

WpfStartupBench_repro.zip

Is this a regression?

yes

Are there any workarounds?

no

[miloush]

Are you able to confirm this is WPF regression rather than .NET one? For example does empty winforms window show the same?

[ekalchev]

I ran the elimination you asked for. Same harness as before (self-contained + ReadyToRun, win-x64, runtime pinned to the SDK, 30 interleaved launches, 3 warmups discarded, medians). Startup measured process-start → first frame (ContentRendered for WPF, Shown for WinForms) and process-start → managed Main for console.

App type	10.0.100	10.0.300	Median delta
WPF (empty window)	538.9 ms	589.7 ms	+50.8 ms (+9.4%)
WPF (menu/toolbar/grid)	626.3 ms	716.7 ms	+90.4 ms (+14.4%)
WinForms (empty form)	89.2 ms	88.8 ms	−0.4 ms (−0.4%)
Console (managed Main)	63.2 ms	58.0 ms	−5.2 ms (−8.2%)

WinForms and console do not reproduce it (console is actually a touch faster on 10.0.300), while WPF regresses on both a trivial and a slightly richer window. So this isn't the host/CoreCLR/JIT/R2R loader.

One caveat on interpreting the WinForms/console results: those apps run very little managed code at startup — they're thin wrappers over native code, so there simply isn't much .NET on their startup path for a managed-side regression to show up on. WPF, by contrast, executes a large amount of managed code before the first frame. So this doesn't fully rule out the shared runtime; it's equally consistent with a regression in managed code that WPF exercises heavily and WinForms/console barely touch. What it does say is that the cost is on a code path WPF depends on and these two do not — most likely the WPF-specific assemblies (PresentationCore / PresentationFramework / WindowsBase / wpfgfx), but possibly shared BCL/managed code that only WPF's startup path hits hard.

[mmanolova-msft]

This looks like a .NET runtime (coreclr) issue rather than WPF

I reproduced it and bisected it to the runtime component and the servicing releases.

Bisection (pinned RuntimeFrameworkVersion across 10.0.0 -> 10.0.8, App1 self-contained + R2R, same interleaved method). The regression lands in two steps, then plateaus:

Runtime	App1 median	Step
10.0.1	~485 ms	baseline
10.0.2	~533 ms	+47 ms
10.0.3	~534 ms	flat
10.0.4	~565 ms	+31 ms
10.0.5-.8	~flat	-

It tracks coreclr, not WPF. A self-contained app loads the DLLs next to it, and the runtime ships as two separate packs - WPF (PresentationCore, PresentationFramework, ...) and the CLR engine (coreclr.dll, clrjit.dll, System.Private.CoreLib.dll). I built hybrids swapping only the WPF DLLs between adjacent versions (CLR engine untouched, verified by version stamp) and measured all four combos:

Config	Median
WPF .2 on coreclr .1	488 ms (fast)
WPF .1 on coreclr .2	543 ms (slow)
WPF .4 on coreclr .3	539 ms (fast)
WPF .3 on coreclr .4	571 ms (slow)

The slowdown follows the coreclr version every time, regardless of the WPF version.

It's a per-workload cost, not a fixed startup tax - so it shows in WPF but not lighter apps (CLR .1 -> .4):

App type	10.0.1	10.0.4	Delta
Console (bare)	281 ms	273 ms	~0
WinForms (empty form)	162 ms	161 ms	~0
WPF (empty window)	~485 ms	~565 ms	+31 ms

The regressed path is type-loading / metadata work; WPF exercises far more of it at startup (DependencyProperty registration, deep type hierarchy, XAML type resolution), so the per-unit cost adds up.

Suggested places to look in dotnet/runtime:

• 10.0.1 -> 10.0.2: Reduce types loaded on startup significantly runtime#120459 - "Reduce types loaded on startup significantly" (special-marker-type / interface-map rework).
• 10.0.3 -> 10.0.4: Fix token memory ordering issue reading from the MethodDef and FieldDef token tables runtime#123557 - "token memory ordering ... VolatileLoad" (self-described "slightly slower" on the MethodDef/FieldDef path); and Fix regression caused by special marker type optimization runtime#123413 - "Fix regression caused by special marker type optimization."

[ekalchev]

Should this be moved in sdk/runtime then?

[mmanolova-msft]

I asked someone from the coreclr team to have a look and will keep you posted

[davidwrighton]

We think this is likely a twofold problem.

1. .NET 10 has an unfortunate type load performance problem in the presence of deep type hierarchies where many methods are not overridden and have not yet been called. I'm working on a fix for this in .NET 11, but it is unclear whether or not a backport to .NET 10 will meet the servicing bar.
2. Servicing builds of .NET 10 were incorrectly configured to use profile guided optimization data from .NET 11 builds. This is in the process of being fixed, and I would expect to see the update come out mid July with that issue fixed. I've asked @mmanolova-msft to look into measuring the performance with the upcoming release of .NET 10, so we can measure how much of an impact this has.