开发者实测 .NET 6.0 到 11 RC 性能：首次调用慢 39% 至 64%，热代码更快

性能 后端开发 Microsoft 微软的代码自 AI 出现以来变差了吗？从 6.0 到 11 RC 测量 .NET 库 Grigorii Moiseev 14 分钟阅读· 刚刚

2022 年 11 月，.NET 7 和 ChatGPT 相隔三周发布。这提供了一个方便的参照点：.NET 7 是 ChatGPT 之前编写的最后一个版本。然后，2025 年 5 月，Copilot coding agent 进入 dotnet/runtime，到 2026 年 10 月底，它在那里提交了 1734 个 pull request，其中 1205 个被合并。 关于 AI 是否毁掉了代码，你可以争论很久，但性能是可以直接测量的。我测量了依赖注入（DI）、配置、日志、缓存和 Entity Framework（EF）Core：46 个操作、六个主要版本、30 轮。我还用 Git 历史检查了谁改动过热方法，并将 11 RC 中的两个回归追溯到具体提交。最大的那个是人类用一行代码引入的。第二个较小的回归来自 Copilot coding agent 的一个修复死锁的 PR。 六个测量点分为三个时代： 这些边界是有条件的：Copilot 自动补全早在 2021 年就出现了。 新的 .NET 版本也会因为 JIT 编译器和垃圾回收器而变快。因此，主赛道将运行时固定为 .NET 10.0.11，只更改 NuGet 包：Microsoft.Extensions.* 从版本 6 到 11，EF Core 从版本 6 到 10（EF Core 11 需要 net11.0，所以其结果中的线停在 10.0）。如果不同主版本的程序集被加载到进程中，运行就会失败。随框架本身一起发布的库（System.Text.Json、Channels、ASP.NET Core）无法这样替换：旧包会输给内置程序集。我将这些库以及 EF Core 11 单独比较，net10.0 对 net11.0，此时库不再能与运行时分离。 以下是其中一项测量，新作用域中的 IOptionsSnapshot：循环 1000 次迭代，每次创建一个作用域并从中解析 IOptionsSnapshot，整个循环包裹在一个计时的作用域中。 时间由 EmberTrace 记录，内存用 GC.GetAllocatedBytesForCurrentThread 计数。每个进程有 20 次预热和 200 次测量迭代，每个场景在各自进程中运行，并固定到逻辑核心 2–5。总共是 30 轮，每个版本–场景对对应 111 个进程，每轮中版本顺序被打乱。 观察单位是进程，所有轮次权重相等。变化在每轮内相对于 7.0 计算，置信区间来自分层 bootstrap，显著性来自带 Benjamini–Hochberg 校正的 Mann–Whitney U 检验。只有当整个 95% 区间超出 5% 阈值、没有任何一轮显示相反结果、且校正后的 p 小于 0.05 时，才判定为“更快”或“更慢”。如果整个区间落在 ±5% 以内，则为噪声，其余一切则不给出结论。 轮次在同一台笔记本电脑（Core i5–12450H，Ubuntu 22.04）的两种状态下运行。“Bench”是性能调节器，关闭 turbo boost，19 轮。“出厂设置”是 powersave，开启 turbo boost，11 轮。为什么这很重要，下面会说明。除非另有说明，以下数字均指 bench。 对于 10.0 对 7.0，46 个操作的统计是：9 个更快，13 个更慢，10 个在噪声范围内，14 个没有结论。双方的典型例子：重复操作到 10.0 快了 14–35%，而首次调用和对象创建慢了 39–64%。 以时间单位看则平静一些。这些值是在运行频率 2 GHz 的笔记本电脑上取得的，所以看数量级即可（7.0 → 10.0）： 对于长时间运行的服务，这种权衡是划算的：日志运行数百万次，而提供程序只构建一次。短生命周期进程则更糟，尤其是使用 EF 时：首次查询贵了 166 ms，这对冷启动来说是一个明显的增加。诚然，冷测量包含 JIT，而且旧包运行在新运行时上，所以这一行的误差比其他行更大。 两种趋势在出厂设置上也可见，但轮次更少，大多数首次调用变慢在形式上仍没有结论。只有 LoggerFactory 被确信地确认：+49%。 争论通常是“神经网络之前更好”，所以让我们看看相邻版本之间的步进。 判定规则相同，只是基线是上一个版本。每一步确认的偏移： 到 10.0 这一步与其前身相比并不突出，尽管 agent 只赶上了其开发的后半年。 在出厂设置上，8.0 没有那么突出（8、7、5 和 6）：只有 11 轮，区间宽了好几倍。但到 11 RC 这一步是吻合的。两种模式都确认了 6 个偏移，6 个操作中有 5 个是共同的。 对跳到 8.0 本身有一个反对意见。每个主包版本带来自己的程序集：7.x 是 lib/net7.0，8.x 是 lib/net8.0，尽管运行时到处都是 .NET 10。这意味着这一步还包括条件编译分支，旧程序集即使在新运行时上也看不到这些分支。那也是库代码，但这种设计无法将代码更改与目标框架的更改分开。 到 10.0 这一步有三个操作突出。new DbContext 贵了 13%，缓存中的 Compact 便宜了 13%，DetectChanges 比 9.0 慢了 19%，回吐了部分收益：相对于 7.0 曾是 −41%，现在是 −30%。 最大的偏移发生在 ChatGPT 之后的第一个版本，这并不能说明 AI 参与其中：测量显示了什么在何时改变，但不显示为什么。 v7.0.20 和 v10.0.14 标签之间对 DI 和 Caching.Memory 的每个提交都已匹配到其 pull request。agent 很容易识别：它的 PR 由 GitHub 应用 copilot-swe-agent 打开，id 为 198982749，squash 提交保留 Co-authored-by 尾注。以下是发现的情况：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）