Can somebody explain
- Why does DbContext.SaveChanges run ~10x slower in debug mode than production mode?
- 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
Update:
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.
Thanks!
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Whohoo!
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
Method 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.
Method 3
As stated in comments, the given answer only works for Visual Studio Ultimate.
As of VS2019 (and probably most other version), the solution is via:
Tools > Options > Debugging > General
Then uncheck Enable Diagnostic Tools while Debugging.
Of course, you’ll lose all the diagnostic bits and bats, but it speeds Entity Framework up immensely if that’s what you’re after.
Update:
The above solution stopped working for me. I’ve found that I needed to further uncheck Show elapsed time PerfTip while debugging from that same list of options.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0