为什么DbContext.SaveChanges 10X在调试模式慢 [英] Why is DbContext.SaveChanges 10x slower in debug mode
问题描述
有人能解释
- 为什么DbContext.SaveChanges不是生产模式下运行在调试模式下〜10倍慢？
- 有什么办法，我可以加快这？
在调试模式下，我的网页需要116秒如果我开始这个项目没有调试加载与15秒。
In debug mode, my webpage takes 116 seconds to load versus 15 seconds if I start the project without debugging.
我已经设置跟踪语句，并确定了的116秒〜100在我的DbContext.SaveChanges方法花费在调试模式下。
I have set trace statements and identified that ~100 of the 116 seconds is spent in my DbContext.SaveChanges method when in debug mode.
运行项目，而不在同一节花了调试只需7秒。
Running the project without debugging only 7 seconds in spent in the same section.
让我知道在评论，如果您想了解更多信息。
Let me know in the comments if you'd like more information..
项目设置：
- ASP.NET网页
- VS2012
- SQLServer2012
- 实体框架5.0
附加信息：（让我知道在评论，如果你需要更多）
Additional Info: (Let me know in the comments if you need more)
- 在SaveChanges方法SQL查询的累积数为20,000
- 生产连接字符串：数据源= PC-DEV;初始目录= ASPNET，2013年6月4日;集成安全性= TRUE; MultipleActiveResultSets = TRUE;应用程序名称= EntityFrameworkMUE
- 调试连接字符串：数据源= PC-DEV;初始目录= ASPNET，2013年6月4日;集成安全性= TRUE; MultipleActiveResultSets = TRUE;应用程序名称= EntityFrameworkMUE
- 我也经历过的LocalDB相同的相对表现为后盾数据库
更新：
由于@ruionwriting的建议，我异形数据库，我发现的是，〜20000 SQL命令采取正是在调试或生产模式下的项目是否运行同一时间。 （每指令0毫秒）。
As @ruionwriting suggested, I profiled the database and what I found is that the ~20,000 sql commands take exactly the same time whether the project is run in debug or production mode. ( 0 ms per command).
但是，在20,000命令之间的平均绝对时间差是在调试模式下5毫秒。
However, the absolute time difference on average between the 20,000 commands is 5ms in debug mode.
与生产方式观照，在命令集的平均时间差为0.3毫秒。
Contrasted with production mode, the average time difference over the set of commands is 0.3 ms.
这是近似的10倍时的性能差异和分离的实体框架是什么花费额外的时间在调试模式下。
This is the approximate 10x time performance difference and isolates entity framework as what is taking the extra time in debug mode.
有没有配置调试版本，这样的EntityFramework无需调试标志引用的方式？
Is there a way to configure the debug build such that EntityFramework can be referenced without debugging flags?
如果我是以某种方式实现性能恢复通过一些编译器魔法，你会失去我调试能力方面？目前，我不能踏进实体框架code，所以我不认为我会错过任何东西。
And if I were to somehow achieve the performance back through some compiler magic, what would I lose in terms of debugging capabilities? Currently I can't step into entity framework code so I don't think I would miss anything.
谢谢！
推荐答案
Whohoo！
好了，原因调试模式格外缓慢是因为Visual Studio的智能跟踪记录是由实体框架生成的每个ADO.NET事件（所有20个，其中有000人）。
Ok, so the reason debug mode was exceptionally slow was because Visual Studio's Intellitrace was recording each ADO.NET event ( all 20, 000 of them ) generated by Entity Framework.
所以工具 - >选项 - >的IntelliTrace和取消选中启用的IntelliTrace解决了该问题。
So Tools-> Options -> IntelliTrace and Uncheck "Enable IntelliTrace" fixed the issue.
或者你也可以使用刚刚的转到工具 - >选项筛选出ADO.NET事件 - >的IntelliTrace - >的IntelliTrace事件，并取消ADO.NET
Or one can also just filter out the ADO.NET events by going to Tools->Options -> IntelliTrace -> IntelliTrace Events and uncheck ADO.NET
感谢大家的建议。
下面一节关于意志的IntelliTrace会谈减慢我的应用程序
这篇关于为什么DbContext.SaveChanges 10X在调试模式慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
