Reputation: 55
I'm trying to get a handle on Entity Framework Performance, specifically around the dynamic SQL it will generate. Take the following statement for instance:
var orders = db.Orders.Include(o => o.OrderItem).Include(o => o.Customer);
Which will return for all orders the order items attached to it and the customer details for the user that ordered it.
Which would roughly translate to SQL such as below:
Select *
from Order o
inner join OrderItem oi on o.OrderId = oi.OrderId
inner join Customer c on o.CustomerId = c.CustomerId
Now (in the context of SQL Server) this plan may be cached and this example is very simple, but as queries become more and more dynamic and complex, with parameters, conditions, variables and so forth, does database performance become an issue with EF and will using Stored Procedures which are compiled or other objects rather than letting EF generate dynamic SQL become more efficient?
Or can we assume that EF is highly optimised, and apart from scenarios where SPROCS, views, functions etc are needed on a database level in complex scenarios, we can rely on EF to be as efficient as possible in its SQL queries?
Upvotes: 1
Views: 817
Reputation: 35219
Quality of EF SQL code is the least thing that should worry you. EF is slow enough by itself. The SQL Server (esp. latest versions) do very good query optimization, so you generally they wouldn't be slower, than, say, some hand-written SPs. But overall, with usage of EF, program will be much slower and less responsive comparing to usage of pure requests a-la ADO.NET + DataTables. That however, doesn't mean EF is bad thing, but you must carefully consider where to use it.
Upvotes: 1