Why is DbContext.SaveChanges 10x slower in debug mode

为什么dbcontext.savechanges 10倍的慢,在调试模式

问题 (Question)

Can somebody explain

  1. Why does DbContext.SaveChanges run ~10x slower in debug mode than production mode?
  2. Is there any way I can speed this up?

In debug mode, my webpage takes 116 seconds to load versus 15 seconds if I start the project without debugging.

I have set trace statements and identified that ~100 of the 116 seconds is spent in my DbContext.SaveChanges method when in debug mode.

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..

Project Setup:

  • ASP.NET webpage
  • VS2012
  • SQLServer2012
  • Entity Framework 5.0

Additional Info: (Let me know in the comments if you need more)

  • The cumulative number of sql queries over the SaveChanges method is 20,000
  • Production Connection String: Data Source=PC-DEV;Initial Catalog=aspnet-2013-06-04;Integrated Security=True;MultipleActiveResultSets=True;Application Name=EntityFrameworkMUE
  • Debug Connection String: Data Source=PC-DEV;Initial Catalog=aspnet-2013-06-04;Integrated Security=True;MultipleActiveResultSets=True;Application Name=EntityFrameworkMUE
  • I've also experienced the same relative performance with LocalDB as the backing database


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).

However, the absolute time difference on average between the 20,000 commands is 5ms in debug mode.

Contrasted with production mode, the average time difference over the set of commands is 0.3 ms.

This is the approximate 10x time performance difference and isolates entity framework as what is taking the extra time in debug mode.

Is there a way to configure the debug build such that EntityFramework can be referenced without debugging flags?

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.



  1. 为什么dbcontext.savechanges运行~ 10倍慢在调试模式下比生产方式?
  2. 有没有什么方法可以快点吗?


我已将跟踪语句和确定,~ 100的116秒都花在我的dbcontext.savechanges方法在调试模式下。




  • ASP.NET网页
  • vs2012
  • sqlserver2012
  • 实体框架5


  • 在SaveChanges方法的SQL查询的累计数是20000
  • 生产数据源连接字符串:= pc-dev;初始目录= aspnet-2013-06-04;综合安全=真实;真实的应用程序名称multipleactiveresultsets =;= entityframeworkmue
  • 调试数据源连接字符串:= pc-dev;初始目录= aspnet-2013-06-04;综合安全=真实;真实的应用程序名称multipleactiveresultsets =;= entityframeworkmue
  • 我也经历过同样的性能相对LocalDB作为后台数据库


“我ruionwriting建议,异型数据库,我发现,~ 20000 SQL命令采取完全相同的时间项目是否运行在调试和生产模式。(0毫秒/命令)。







最佳答案 (Best Answer)


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.

So Tools-> Options -> IntelliTrace and Uncheck "Enable IntelliTrace" fixed the issue.

Or one can also just filter out the ADO.NET events by going to Tools->Options -> IntelliTrace -> IntelliTrace Events and uncheck ADO.NET

Thanks for everyone's suggestions.

A section here talks about Will Intellitrace slow down my app

How to Filter IntelliTrace Events


好的,所以调试模式非常慢是因为Visual Studio的IntelliTrace是记录每个ADO.NET事件(20,000)的实体框架生成。

Options -> IntelliTrace and">工具->选项-> IntelliTrace和取消选中“启用IntelliTrace”固定的问题。

或者也可以NET事件过滤Options -> IntelliTrace -> IntelliTrace Events and uncheck ADO.NET">在“工具->选项-> IntelliTrace -> IntelliTrace事件和取消ADO.NET




答案 (Answer) 2

There are multiple performance considerations for EF and it's known that, compared to many others orm's, operations can be slower than expected/desired for an orm.

(1st) when running on debug will always be slower and (2nd) first run after building will always be slower.

All of this may depend on the complexity of your model. Try to capture the T-SQL statements using SQL Profiler.