Note: We have create a separate item to track the
performance issue with the debugger attached . Aside from this issue, there is still a performance regression without the debugger attached in this bug report that needs to be understood.
We are working on a new crm application using entity-framework and I am seriously scared if we will soon get to the point
where developing with EF gets highly unproductive because of the extremley poor startup performance.
We started using EF since the EF 6.0 Alpha1 release, and were on RC1 for some months now.
In the hope that startup performance has increased, I have updated the solution to EF 6.0.1 today.
Unfortunately startup performance is even worse than in RC1 and I am seriously concerned about that poor performance.
Let me share you some stats of our new application:
- Currently we have about 55 Entities (Code first)
- First Query Performance with attached debugger: ~ 10 seconds (EF 6 RC1)
- First Query Performance without debugger: ~ 5 seconds (EF 6 RC1)
- First Query Performance with attached debugger: ~ 15 seconds (EF 6.0.1)
- First Query Performance without debugger: ~ 7 seconds (EF 6.0.1)
Hardware: DualCore 2.5 Ghz Core2, 4GB Ram
As you can see, every time a developer hits F5, we have to wait for about 10-15 seconds until the applications is usable.
That's pretty bad, even if the performance is currently still acceptable.
But this is only the beginning:
Planned Future Status:
The application is rapidly evolving at the moment, and If all parts are implemented, we are expecting to have about 200-300 entities in the final stage.
So this is my quick estimation of the apps expected final startup performance:
- Expected final entities: 300
- This is about 6 times more than now ...
- ... expected first query performance with debugger: ~ 10*6 = 60 seconds (EF 6 RC1)
- ... expected first query performance without debugger: 20-30 seconds (EF 6.0 RC1)
What do these numbers indicate:
If we continue using ef, every developer hitting (F5) will have to wait 1 minute until the app is usable.
That means, if the application is finally launched, the developer has probably forgotten what he wanted to do at all.
The end-user has to wait 30 seconds for the app to be initialized. That means that the app will have a bad reputation because of the slow startup.
These are pretty bad perspectives and I need to know if there is a solution for this performance problem.
The sample code
I really hope that you, the highly talented ef developer team, can significantly reduce this startup penalty.
So I prepared a sample project, where I extracted the following parts of our solution:
- code-first conventions
- anonymized sample-domain
Since I cannot share our complete real domain, I extracted some root entities (VersionedEntity, User, Catalogue)
and created some faked entities which have similar properties as our real entities (Company, Person etc.).
I then duplicated them 100 times so that the final domain includes about 100 entities to simulate the size of our future domain with about 100 entities. (and we are expecting over 200!)
The benchmark output is worse than expected:
- 108 Entities ...
- First Query with attached debugger: ~ 1.45 Minutes
- First Query without debugger: 22 Seconds
When I add a precompiled view file the following exception is raised: "The current model no longer matches the model used to pre-generate the mapping views." (seems to be a bug)
However, these are the times of how long it takes until the exception is raised:
- With attached debugger: 1.28 Minutes
- Without attached debugger: 10 seconds
Even if these would be the final times (but I am expecting some additional seconds) it is too slow since starting with a debugger still consumes 1.30 minutes.
Also keep in mind that this is a 100-entities sample (and we are expecting 200-300 entities!)
- Is there any hope that you can significantly optimize the first query performance so that a 200 entity-domain with our complexity is ready in a reasonable time when hitting (f5) ("reasonable" means max 15 seconds with a debugger and max 10 seconds
- The "Attached-Debugger" overhead is massive. Is this solely because of the missing JIT-Optimizations or are there some hidden if(Debugger.Attached) paths?
- Would it be possible that you could somehow serialize the entity-model-mapping-graph to a binary-file and than load it at startup so that the compilation of the entity-model is cached? (I am not talking about view generation)
- Microsoft is advertising entity-framework as "the recommended OR-Mapping solution". I am curious how anybody can use this technology in a seriously big domain if the startup-penalty is that big? Is our domain that special or do all EF-Devs take
a coffee break when starting their big application?
Please have a look at the attached solution. Everything is cleanly organized so that you can easily understand the structure.