Slower build times with SDK 10 compared to 8

[jairbubbles]

Describe the bug

While testing SDK 10 on a net8.0 solution (no TFM change, just the version in global.json), I noticed increased build times by something like 50%.

After some investigation, it doesn't seem to be linked to analyzers but to the Csc tasks taking more time.

To Reproduce

The initial project on which I noticed the issue is internal so I looked for an open source project on which I can reproduce the issue and pick https://github.com/aws/aws-sdk-net/

• Just clone the project and restore the packages.
• Then I'm using hyperfine to compare build times (to make sure analyzers are out of the equation I'm passing /p:RunAnalyzersDuringBuild=false):

hyperfine -L config "Debug" -L sdk_version "8.0.407,10.0.101" -N --setup "dotnet new globaljson --sdk-version {sdk_version} --force" --prepare "dotnet clean AWSSDK.NetStandard.sln /p:Configuration={config}" "dotnet build AWSSDK.NetStandard.sln --no-restore /p:Configuration={config} /p:RunAnalyzersDuringBuild=false"

• It will build several times so it will take some time and then I get:

dotnet build AWSSDK.NetStandard.sln --no-restore /p:Configuration=Debug /p:RunAnalyzersDuringBuild=false (sdk_version = 8.0.407) ran
    1.91 ± 0.12 times faster than dotnet build AWSSDK.NetStandard.sln --no-restore /p:Configuration=Debug /p:RunAnalyzersDuringBuild=false (sdk_version = 10.0.101)

It's almost 2 times slower 😩

binlog investigation

When I compare the binlogs I see that we're taking a lot more time in the Csc tasks.

SDK 8:

SDK 10:

I compared the Csc command lines but I didn't see any relevant differences.

I don't know how to dig further so I finally opened this issue.

Further technical details

details of dotnet --info

SDK .NET :
 Version:           10.0.101
 Commit:            fad253f51b
 Workload version:  10.0.100-manifests.c57ac48b
 MSBuild version:   18.0.6+fad253f51
Environnement d'exécution :

OS Name:     Windows

OS Version:  10.0.26200

OS Platform: Windows

RID:         win-x64

Base Path:   C:\Program Files\dotnet\sdk\10.0.101\
Charges de travail .NET installées :

Il n'y a aucune charge de travail installée à afficher.

Configuré pour utiliser desworkload sets lors de l’installation de nouveaux manifestes.

Aucun ensemble de charges de travail n’est installé. Exécutez « dotnet workload restore » pour installer un ensemble de charge de travail.
Host:

Version:      10.0.1

Architecture: x64

Commit:       fad253f51b
.NET SDKs installed:

8.0.407 [C:\Program Files\dotnet\sdk]

9.0.100 [C:\Program Files\dotnet\sdk]

9.0.201 [C:\Program Files\dotnet\sdk]

9.0.305 [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 8.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 9.0.9 [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 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.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 9.0.9 [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 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.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 9.0.9 [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:

Not set
global.json file:

D:\Git\aws-sdk-net\sdk\global.json

[Yozer]

We're also seeing significant performance degradation in build times in .net10 (when compared to .net9).
It's much slower to a point where we had to double our build machines capacity to handle it... Not to mention degraded local development expirence.
The test below was done on a small service, on the main component build times went up from roughly 4mins to 8mins.
Pretty much happens in all our projects and doesn't matter if its Windows/Linux.

9.0.305 [C:\Program Files\dotnet\sdk]
10.0.101 [C:\Program Files\dotnet\sdk]

dotnet build Service\XXX.csproj -bl -c Release -f net10.0 -p:RunAnalyzersDuringBuild=false
Build succeeded in 35,9s

dotnet build Service\XXX.csproj -bl -c Release -f net9.0 -p:RunAnalyzersDuringBuild=false
Build succeeded in 18,2s

I've noticed that in the binary log (timing from the root project I'm building):
net9.0:

net10.0:

Happy to share the bin log if needed.

[jjonescz]

Even if it's not analyzers, it can be source generators. Consider passing also /p:ReportAnalyzer=true to include timing details.

Happy to share the bin log if needed.

Yes, please. You can share it privately via a comment under a ticket created on https://developercommunity.microsoft.com/dotnet/report (and linking the ticket here). Thanks.

[Yozer]

@jjonescz Done: https://developercommunity.microsoft.com/t/Slower-build-times-with-SDK-10-compared/11014243

net9:

net10:

They're slightly slower but not enough to justify the increase that I'm seeing.

[jairbubbles]

Same here, slightly slower:

.NET 8:

.NET 10:

[jjonescz]

@Yozer thanks for the binlogs. I see also quite big differences in other tasks (in the "Top 10 most expensive tasks" section of the binlog) like ResolvePackageAssets (704 ms vs 2.688 s) which to me suggests something unrelated to the C# compiler is wrong, like I/O might be slower (e.g., antivirus blocking file reads/writes or executions of the new dotnet).

[jairbubbles]

That's something I suspected too (especially on my corporate machine) but my latest results are from my personal machine on which I don't specific antivirus rules.

The whole "dotnet" folder is excluded:

[Yozer]

@jjonescz I can make some extra tests for the same code base on machine that has all AV disabled if you want but we're seeing slow builds also on our build machines with linux and we don't have any AV there.

[jjonescz]

AV was just one theory. The real question is whether you see only Csc task slower or other tasks too, so we can direct the investigation in the right direction.

[tfabraham]

We're also seeing the same dramatic slowdown and large increase in CPU usage.

We were on the latest .NET 9 SDK via Visual Studio 2022 with the latest patches, targeting .NET 9. As soon as we installed Visual Studio 2026 (and builds switched to the .NET 10 SDK), our builds began running much slower. On our build server we went from 6-7 min builds to 10-14 mins. On my laptop, I started noticing the fans spinning up to full speed and CPU usage virtually maxing out during builds, which didn't happen before.

To be clear, nothing changed other than installing Visual Studio 2026. No changes to our solution, code, projects, still targeting .NET 9.

It appears that the extra time is being spent in Csc and that's when the CPU usage spikes too. I tried turning off code analysis but that didn't seem to make a difference.

It's bad enough we've had to roll back to the .NET 9 SDK. Our team productivity took a huge hit waiting so much longer for builds both locally and on our build server.