Live Nov 18 · Cohort 3Nov 18, 19:00 MSK — free hands-on AI agents live workshop · Live Cohort 3 starts Nov 23Join Nov 18 Live →Cohort 3 (Nov 23)
ReleaseResearch Paper · For R&DHabr AI→ original

Benchmarking 46 .NET Operations: Copilot Agent Adds a 16% Slowdown to First DI Resolve

The author ran 46 operations across DI, configuration, logging, caching and EF Core on six .NET versions: 30 rounds, runtime pinned. Two slowdowns in 11 RC were traced back to commits. The largest, ×2.4 on configuration binding, was introduced by a human with a single line; the second, +16% on first resolve in DI, came from a Copilot agent PR.

AI-processed from Habr AI; edited by Hamidun News
Benchmarking 46 .NET Operations: Copilot Agent Adds a 16% Slowdown to First DI Resolve
Source: Habr AI. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceHabr AI ↗
Editor-in-Chief
POCO binding in 11 RC61 → 145 µs because of a single attribute check
Agent's PR against a deadlock+0.9 µs on first resolve in DI
Workaroundthe source generator gives 12 µs versus 29 µs in 10.0

The debate over whether AI ruins code usually runs on gut feeling. The author of this piece decided to measure it. He picked a baseline: .NET 7 shipped three weeks before ChatGPT and was the last release written before the era of assistants. Since May 2025, the Copilot coding agent has been working in dotnet/runtime: by the end of October 2026 it had opened 1734 pull requests, 1207 of them merged.

How the measurements were done

The runtime was pinned to .NET 10.0.11, and only the Microsoft.Extensions.* NuGet packages from version 6 to 11 and EF Core from version 6 to 10 were changed. This way, JIT and GC improvements do not affect the result. In total: 46 operations, 30 rounds, each scenario in a separate process on dedicated cores, with version order shuffled. A verdict of "faster" or "slower" is issued only if the entire 95% confidence interval lies beyond a 5% threshold.

The first picture is ambiguous. Version 10.0 versus 7.0: 9 operations faster, 13 slower, 10 within noise. Warmed-up code got 14–35% faster: LoggerMessage.Define went from 377 to 244 ns, DetectChanges on 10 thousand entities from 6.1 to 4.3 ms. But first calls and object creation became 39–64% more expensive: the first EF query grew from 996 to 1162 ms. For a long-lived service the trade-off is favorable; for short-lived processes and cold start it is not.

The most shifts, 19 out of 46, came in the step to 8.0, the first release after ChatGPT. But the author honestly notes that the measurements show what changed, not why. Moreover, this step includes a change of target build from net7.0 to net8.0.

Where the agent was

In the Git history between v7.0.20 and v10.0.14, 113 commits were found in DI and caching, none from the agent. In the window leading up to 11 RC the agent appeared: for example, 3 of 11 changes to hot DI and cache methods. An important caveat: an agent commit means "the PR was opened by the agent", not "written without a human". All PRs are reviewed by humans, and an IDE assistant is not visible in Git at all.

Two slowdowns in 11 RC

The largest: binding a 50-field POCO grew from 61 to 145 µs, and IOptionsSnapshot in a new scope from 52 to 136 µs. The cause was found in a single line from PR #126396 with the [ConfigurationIgnore] attribute: property.IsDefined(...)

is executed for every property on every binding. The author built the binder from source, replaced the expression with false and swapped a single DLL: the time returned to 60 µs. Most of the cost comes from the overload with inherit: true by default.

The PR was written by a human. The maintainers acknowledged the regression but reminded that the source generator is recommended for hot paths. A fix for 11.

0 is promised but not guaranteed: the issue is tied to milestone 12.0.0.

The second slowdown is smaller: first resolve in DI grew by 16.5%. A commit bisect pinpointed the culprit, agent PR #124331, which fixes a deadlock with circular dependencies through factories. Now VisitRootCache maintains a ThreadStatic HashSet, which costs about 0.9 µs per first resolve. Reverting only this PR brings the time back to the 10.0 level. The commit does not affect warmed-up singleton, scoped, or provider building. The author considers the price reasonable for a fixed deadlock.

What to do

  • If you are on 11 RC and bind configuration a lot, enable the source generator (EnableConfigurationBindingGenerator): 12 µs versus 29 µs in 10.0.
  • Instead of IOptionsSnapshot, where per-request refresh is not needed, use IOptionsMonitor.
  • Watch cold start: it became more expensive in several places.

Limitations: this is a release candidate, the measurements were run on a single laptop, and the main track uses the 11.0 build on the .NET 10 runtime. The takeaway on AI is modest: neither slowdown proves that AI makes code worse. One was introduced by a human, the other by an agent in exchange for fixing a real bug. But a methodology in which regressions are caught by measurement and bisect is worth more than any debate.

Story

Key Questions Answered

How the measurements were done?

The runtime was pinned to .NET 10.0.11, and only the Microsoft.Extensions. NuGet packages from version 6 to 11 and EF Core from version 6 to 10 were changed. This way, JIT and GC improvements do not affect the result. In total: 46 operations, 30 rounds, each scenario in a separate process on dedicated cores, with version order shuffled. A verdict of "faster" or "slower" is issued only if the entire 95% confidence interval lies beyond a 5% threshold. The first picture is ambiguous.

Where the agent was?

In the Git history between v7.0.20 and v10.0.14, 113 commits were found in DI and caching, none from the agent. In the window leading up to 11 RC the agent appeared: for example, 3 of 11 changes to hot DI and cache methods. An important caveat: an agent commit means "the PR was opened by the agent", not "written without a human". All PRs are reviewed by humans, and an IDE assistant is not visible in Git at all.

What are the key details on Two slowdowns in 11 RC?

The largest: binding a 50-field POCO grew from 61 to 145 µs, and IOptionsSnapshot in a new scope from 52 to 136 µs. The cause was found in a single line from PR #126396 with the [ConfigurationIgnore] attribute: property.IsDefined(...) is executed for every property on every binding. The author built the binder from source, replaced the expression with false and swapped a single DLL: the time returned to 60 µs. Most of the cost comes from the overload with inherit: true by default. The PR was written by a human.

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Hands-On AI Engineering · Hamidun Academy

Build & Ship Production AI Agents Without Boilerplate Code

Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.

Start 72h Free Trial →Vibe-Coding Intensive
What do you think?
Loading comments…