.NET 11 RC doubles configuration binding cost, 46 benchmarks show
A benchmark study measures 46 DI, configuration, logging, cache and EF Core operations from .NET 7.0 to 11 RC on a fixed .NET 10 runtime, and cross-checks the findings against Git history to see what the Copilot coding agent actually touched. Warm paths got faster, first calls got slower, and 11 RC carries a regression that roughly doubles reflection-based configuration binding.
Key points
- Across 46 operations from 7.0 to 10.0, 9 got faster, 13 slower, 10 stayed inside noise and 14 got no verdict.
- In 11 RC, 50-field POCO binding went from 61 µs to 145 µs and IOptionsSnapshot from 52 to 136 µs, with roughly 10 KB extra allocation per call.
- The cause is an IsIgnoredProperty() check for [ConfigurationIgnore] running per property per bind; issue #136759 and PR #136899 are still open.
- EnableConfigurationBindingGenerator brings the same binding down to 12 µs and 5.7 KB, beating even the 10.0 reflection binder.
- First DI resolve grew about 15% in 11 RC; a bisect traced it to agent PR #124331, the deadlock fix, for roughly 0.9 µs per provider.
- Git history shows no Copilot agent commits in DI or Caching.Memory up to 10.0; in the 11 RC cycle the agent wrote 11 of 21 DI commits and 73 of 256 EF Core commits.
Three weeks after .NET 7 shipped in November 2022, ChatGPT went public, giving the author a convenient boundary. He benchmarked 46 operations across DI, configuration, logging, caching and EF Core from .NET 7.0 to 11 RC, keeping the runtime pinned to .NET 10.0.11 and swapping only the NuGet packages (EF Core stops at 10.0, since 11 requires net11.0). Against 7.0, warm paths got 14-35% faster while first calls and object creation became 39-64% slower.
The sharpest regression sits in 11 RC: POCO binding of 50 fields rose from 61 µs to 145 µs and IOptionsSnapshot from 52 to 136 µs. A new [ConfigurationIgnore] check added in PR #126396 runs for every property on every bind; stubbing that line restores 10.0 timings. Issue #136759 is open and the fix PR is unmerged, so the source generator is the practical workaround today.
Real-world use
- A high-traffic ASP.NET Core API using IOptionsSnapshot that needs to know the per-request cost of recreating options.
- A worker service binding configuration into a 50+ field POCO that must be measured before moving to .NET 11.
- A container or Lambda workload where cold start matters, tracking the first EF Core query and provider build time.
- A team library whose hot methods are traced with git log -L and bisected commit by commit across releases.
Why it matters
If you move to .NET 11, reflection-based configuration binding and IOptionsSnapshot can become about twice as slow, so switch those paths to the source generator or IOptionsMonitor before they reach production request handling.