Severe performance regression in .NET 10 vs .NET 9 for xUnit v3 test execution

[Schaeri]

Description

After upgrading our solutions from .NET 9 to .NET 10, we observe a ~80–90% slowdown when executing xUnit v3 tests using the xUnit v3 In-Process Runner (direct EXE execution, not dotnet test or with dotnet run).

Profiling shows that the regression is mostly in gc and system code.

With a simple sample test project, we can demonstrate the problem.

Configuration

• .NET SDK: 10.0.101
• .NET Runtime: 10.0.1
• Comparison baseline: .NET 9.0.11
• Windows x64
• xUnit.net v3.2.1
• xUnit v3 In-Process Runner
• Tests executed by directly running the compiled test EXE with dotnet run
  (not via dotnet test, no Microsoft Testing Platform)

Analysis

PerformanceNet9vsNet10Tests.zip

The sample project contains 10,000 test classes, all of which are copies of test class 1. These generate a certain amount of memory and CPU load.

Using run.bat, the tests are executed first on .NET 9.0 and then on .NET 10.0—once in Debug mode and once in Release mode.

.NET 9.0 Debug: 2.103 s vs .NET 10 Debug: 4.9 s
.NET 9.0 Release: 2.137 s vs .NET 10 Release: 5.254 s

The execution time increases significantly in all cases.

JetBrains dotTrace output
Settings: Sampling, Realtime CPU Instruction

Top Hotspots in the System namespace:

This issue leads to increased build pipeline wait times and higher costs. What mitigation options are available? Could this be a runtime-related problem associated with the optimizations in .NET 10?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[mangod9]

direct EXE execution, not dotnet test or with dotnet run

so the regression doesnt show up with dotnet test or just that it can't be run with it. Also is there a specific test which is slowing down or all tests show a regression ?

Thanks

[agocke]

I can see the regression in wall-clock time locally, but I'm not convinced GC has anything to do with it.

net9:
•Total CPU Time: 100,528 msec
•Total GC CPU Time: 2,391 msec
•Total Allocs : 3,405.962 MB
•Number of Heaps: 1
•GC CPU MSec/MB Alloc : 0.702 MSec/MB
•Total GC Pause: 2,460.7 msec
•% Time paused for Garbage Collection: 11.5%
•% CPU Time spent Garbage Collecting: 2.4%
•Max GC Heap Size: 154.787 MB
•Peak Process Working Set: 434.479 MB
•Peak Virtual Memory Usage: 2,481,173.164 MB

net10:
•Total CPU Time: 87,464 msec
•Total GC CPU Time: 2,335 msec
•Total Allocs : 3,404.789 MB
•Number of Heaps: 1
•GC CPU MSec/MB Alloc : 0.686 MSec/MB
•Total GC Pause: 2,302.1 msec
•% Time paused for Garbage Collection: 13.7%
•% CPU Time spent Garbage Collecting: 2.7%
•Max GC Heap Size: 154.416 MB
•Peak Process Working Set: 336.245 MB
•Peak Virtual Memory Usage: 2,342,052.446 MB

[Youssef1313]

A guess here, the threadpool grows faster in .NET 9, somehow.

Trying to pause debugger at random points with .NET 10:

With .NET 9, I always see more TP threads doing work:

[agocke]

@eduardo-vp could you take a look?

[Schaeri]

@mangod9

Thanks for investigating.

The tests can be run with dotnet test; we simply don’t use it in our CI/CD pipeline.

The regression is not limited to specific tests. It affects everything from simple unit test projects to complex integration tests (SQLite, test host). The slowdown scales with test count and complexity: small projects show ~20% regression, while others exceed 2× runtime. On average, we see ~80–100% slowdown.

The sample project contains Copilot-generated unit tests to reproduce the issue with minimal complexity.

[agocke]

Interestingly I don't see this regression on Linux -- in fact, it seems like net10 is slightly faster.