为什么 DbContext.SaveChanges 在调试模式下慢 10 倍答案

【问题标题】：Why is DbContext.SaveChanges 10x slower in debug mode为什么 DbContext.SaveChanges 在调试模式下慢 10 倍
【发布时间】：2013-05-31 07:54:25
【问题描述】：

谁能解释一下

在调试模式下，我的网页加载需要 116 秒，而如果我在不调试的情况下启动项目则需要 15 秒。

我已设置跟踪语句并确定在调试模式下，116 秒中的大约 100 秒用于我的 DbContext.SaveChanges 方法。

在同一个部分只用了 7 秒的时间在不调试的情况下运行项目。

如果您想了解更多信息，请在 cmets 中告诉我。

项目设置：

附加信息：（如果您需要更多信息，请在 cmets 中告诉我）

SaveChanges 方法的 sql 查询累计数为 20,000
生产连接字符串：数据源=PC-DEV；初始目录=aspnet-2013-06-04；集成安全=True；MultipleActiveResultSets=True；应用程序名称=EntityFrameworkMUE
调试连接字符串：数据源=PC-DEV；初始目录=aspnet-2013-06-04；集成安全=True；MultipleActiveResultSets=True；应用程序名称=EntityFrameworkMUE
我也体验过使用 LocalDB 作为后备数据库的相同相对性能

更新：

正如@ruionwriting 建议的那样，我分析了数据库，发现无论项目是在调试模式还是生产模式下运行，大约 20,000 条 sql 命令所花费的时间完全相同。（每个命令 0 毫秒）。

但是，在调试模式下，20,000 条命令之间的平均绝对时间差为 5 毫秒。

与生产模式相比，这组命令的平均时间差为 0.3 毫秒。

这是大约 10 倍的时间性能差异，并将实体框架隔离为在调试模式下花费额外时间的原因。

有没有办法配置调试版本，以便在没有调试标志的情况下引用 EntityFramework？

如果我通过某种编译器魔法以某种方式恢复性能，那么在调试能力方面我会失去什么？目前我无法进入实体框架代码，所以我想我不会错过任何东西。

谢谢！

【问题讨论】：

调试时你的连接字符串是什么样子的？
@RealityDysfunction 在生产和调试模式下用字符串更新了问题。
您是否在 VS 中选中了“仅启用我的代码”？在 Debug Menu->Options and Settings->General->Enable Just My Code 下。也许您没有检查，而 VS 正在尝试调试 EF？
@Tombala，即使检查过，性能也一样差。 :(

【解决方案1】：

哇！

好的，所以调试模式异常缓慢的原因是因为 Visual Studio 的 Intellitrace 正在记录 Entity Framework 生成的每个 ADO.NET 事件（全部 20, 000 个）。

So Tools-> Options -> IntelliTrace 和 取消选中“启用 IntelliTrace” 修复了该问题。

或者也可以通过转到工具 -> 选项 -> IntelliTrace -> IntelliTrace 事件并取消选中 ADO.NET 来过滤掉 ADO.NET 事件

感谢大家的建议。

【讨论】：

【解决方案2】：

EF 有多个 performance considerations，众所周知，compared 对许多其他 orm 来说，操作可能比预期/期望的 orm 慢。

(1st) 在调试时运行总是比较慢，(2nd) 在构建后第一次运行总是比较慢。

所有这些都可能取决于您的模型的复杂性。试试capture the T-SQL statements using SQL Profiler。

【讨论】：

【解决方案3】：

如 cmets 中所述，给定答案仅适用于 Visual Studio Ultimate。

从 VS2019（可能还有大多数其他版本）开始，解决方案是：

工具 > 选项 > 调试 > 常规

然后取消选中在调试时启用诊断工具。

当然，您会丢失所有诊断信息，但如果您要这样做，它会极大地加快实体框架的速度。

更新：

上述解决方案不再为我工作。我发现我需要从同一个选项列表中进一步取消选中 Show elapsed time PerfTip while debugging。

【讨论】：