Last post Mar 10, 2015 10:21 AM by itpreneur
Mar 07, 2015 05:29 AM|damon2012|LINK
some user report bad performance with EF. What is the reality of the performance in version 6. You can also call stored procedures from EF so if you ran into performance issues would this nullify some of them?
Mar 07, 2015 05:50 AM|Mikesdotnetting|LINK
For the most part, EF6 performance is fine. You *might* find for some complex queries that the SQL it generates is not optimal, in which case you can either get it to execute raw SQL or a stored procedure.
Mar 09, 2015 02:40 AM|Kevin Shen - MSFT|LINK
For your issue ,I suggest that you could refer to the link to check the Performance Considerations for Entity Framework 4, 5, and 6:
and some tips about how to improve performance:
Mar 10, 2015 10:21 AM|itpreneur|LINK
There are some good and bad side of Entity Framework. Performance wise it is not too bad if you design your model wise and limit the # of entities inside your DDD.
Why limit? Let's take for a very basic example.
Let's say you have a One to One relationship with Student and Address. The requirements is when you add a student, it should have some address on it.
Assuming you're in ADD operation, in EF, you would see two INSERTs statement sent (one INSERT for Student and one INSERT for Address). It may have a little significant in terms of performance at this point, but you grow your columns in each of these entities
and you grow your entities, imagine the # of INSERT statement being sent to SQL as opposed to one STORED PROC. 2 database trip vs. 1 database trip because of STORED PROC.
This is one example.
Other examples will be what the performance consideration indicated by the other guy. Lazyloading, proxyenable,validationenabled, etc. If these are turned ON which you don't need it for your particular query, then you will have significant impact. Imagine
the example of Student/Address. If lazyloading is ON and you only need to load student and not the address, If Lazyloading is turned ON by default, any related entities are being loading even if it you don't need it.
Another input, during first time execution, you'll see some minor performance hit since EF loads the metadata. Normally, the READ/UPDATE/DELETE has some disadvantages for EF in terms of performance as opposed to low level ADO.Net.
Another point, compiled LINQ is advisable. There are so many things to consider and your best analysis is to capture it with Sql Profiler and observe how many ms/sec spend on your operation and how many database trip does it make with your operation. I've
seen lots of developers creating mulitple linq and combine them together thus making a lot of database trip as opposed to stored proc.