[Performance] Startup time is bad with debugger attached


This item is about the perf regression we have seen when the debugger is attached. It was reported in several places, including bug #1749, but that bug describes other issues that need to be addressed separately.

The cause of the startup performance deterioration with the debugger attached is that our metadata collections use Lazy<T> in a way that triggers numerous invocations of Debugger.NotifyOfCrossThreadDependency() at model creation time. This call is very expensive when there is a debugger attached.
Closed Nov 5, 2013 at 11:16 PM by lukew
Startup performance with the debugger attached is still slower in 6.0.2, but it is no slower than without the debugger attached. I tested with EDMX models and code first models and attaching the debugger no longer seems to have a significant impact on startup performance


emilcicos wrote Oct 31, 2013 at 8:43 PM

commit 833024085582516ee8a5b91dccae1be3fd466dc0

lukew wrote Oct 31, 2013 at 11:16 PM

Master: Commit fab96d21d258a37a41ab8ffb96a0e6b3f56f3697

james1301 wrote Nov 1, 2013 at 1:26 PM

Any idea on when 6.02 will be released? This is slowing us down a bit, but don't really want to go to a pre-release build.

ErikEJ wrote Nov 1, 2013 at 2:01 PM

See the ado.net blog

RoMiller wrote Nov 1, 2013 at 8:17 PM

Details on the 6.0.2 patch we are working on are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx

luizfbicalho wrote Nov 6, 2013 at 8:08 PM

To avoid problems in MVC projects I use one DbContext for each Request using Unity.MVC
Couldn't the DbContext Constructor receive one parameter (for example) DbContextModel that could be a singleton and this model could have all the process in startup done?

Or even simpler:

Two instances of dbcontext, one as singleton and one created per request, and I pass the singleton in the per request constructor, and the constructor uses all the loaded information from the dbcontext that is in the singleton.

This could work?