Performance Regression: .NET 10.0.101 build takes 300s (was 25s in 10.0.100)

[IkertxoBasetis]

I am experiencing a build time regression in a .NET project. Updating the SDK from 10.0.100 to 10.0.101 increases build time from 25s to 300s.

I can reproduce the issue isolating the SDK version, enforced using global.json:

{
  "sdk": {
    "version": "10.0.101",
    "rollForward": "disable"
  }
}

Except the "10.0.100" or "10.0.101" line the rest of the code is just the same.

Repro steps

I am attaching screenshots of running the following command:

dotnet build --no-restore -bl -c Release XXX.fsproj

• 10.0.100

and

• 10.0.101

and

Is there any way to share the full binlog anonymously?

Related information

• I also tried disabling the antivirus, but the results are similar.

• The issue is reproducible on other machines. A coworker with a clean checkout experienced the same regression immediately after updating to the last Visual Studio 2026 version.

Click to expand dotnet --info

dotnet --info .NET SDK: Version: 10.0.101 Commit: fad253f51b Workload version: 10.0.100-manifests.9f71effe MSBuild version: 18.0.6+fad253f51

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.101\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.1
Architecture: x64
Commit: fad253f51b

.NET SDKs installed:
8.0.416 [C:\Program Files\dotnet\sdk]
10.0.100 [C:\Program Files\dotnet\sdk]
10.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.31 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.31 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
DOTNET_CLI_TELEMETRY_OPTOUT [1]

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

[majocha]

Hi, this is most probably type subsumption cache regression that went into 10.0.101. To confirm you could build with --times switch added to <OtherFlags> and then search for typeSubsumptionCache in the binlog.

Another way is to set <LangVersion>9.0</LangVersion> to disable the cache.

[T-Gro]

@majocha : The difference between .100 and .101 (based on Tags in the dotnet/dotnet virtual monorepo) was the prevention of infinity cacheKey (capping at 256) and in consequence not caching for them AFAICS.

There might be a degenerate scenario in which non-infinite-but-large keys are generated (=costs CPU), and then end up not having the cache benefit.

@IkertxoBasetis:
The report from the <OtherFlags>--times</OtherFlags> will only contain overall timings and cache hit/cache miss ration. If you would not mind sharing the publicly, you can paste it here. Alternatively you can use the Visual Studio "send feedback" mechanism to share private data and/or dumps.

[T-Gro]

@majocha :
I think the most needed thing in general for overarching build time changes would be to get a lot more real-world testing exposure at PR time. The nature of .NET and/or VS release train gives us a very slow feedback cycle and it takes months before change makes it to customers, during which time the feature could have been improved a few times already.

I tried to bootstrap that with the regression testing pipeline, but so far it only focuses on quality.
If you have any ideas w.r.t. to other relevant metrics, I could try to integrate it in ( the pipeline could e.g. enforce passing additional flags to the compilation of referenced projects, but we would also need to know with that information - e.g. what to do with cache hit/miss ratio).

[IkertxoBasetis]

Thanks for the quick response.

I can confirm that setting the project to <LangVersion>9.0</LangVersion> effectively returns the build times to normal.

I’ve attached the --time output below, though I suspect it just confirms what you already know.

Is there any other test I can run to help? For context: this is the project where all our types are defined. It relies extensively on Units of Measure and the FSharp.UMX library, which might be relevant to the regression

Time.txt

[majocha]

I tried to bootstrap that with the regression testing pipeline, but so far it only focuses on quality. If you have any ideas w.r.t. to other relevant metrics, I could try to integrate it in ( the pipeline could e.g. enforce passing additional flags to the compilation of referenced projects, but we would also need to know with that information - e.g. what to do with cache hit/miss ratio).

CI is not great for reproducible build times, but detection of huge ~1000% outliers like in this case would be good. As for the cache I'd expect very different usage profiles from project to project but we could just detect pathological situations like low hit ratio with absolute number of misses in the tens or hundreds of thousands -- affecting build times negatively for sure:

Yep, like this:

--------------------------------------------------------------------------------------------------------------------
|             Cache name              | hit-ratio |  adds  | updates | hits  | misses | evictions | eviction-fails |
|-------------------------------------|-----------|--------|---------|-------|--------|-----------|----------------|
| typeSubsumptionCache                |    4,49 % | 409646 |       0 | 19261 | 409646 |         0 |              0 |

[T-Gro]

@IkertxoBasetis :

Thanks for the report. Yes, it can be the FSharp.UMX usage in combination of a new (LangVersion 10) feature.
We should fine some big enough OSS codebase (over)using FSharp.UMX and UoM extensively and make it a compiler regression test.