CODEWITHSUNDEEP
c#entity-frameworkado.net
daz-fuller
daz-fuller

Reputation: 1231

Entity framework and linq to entity performance

I've been investigating using Microsoft's entity framework for a project at work. I created a simple little data layer solution which has an IDataService interface so I could write a standard ADO.Net implementation and an Entity Framework version using Linq-to-Entity.

I've created two tests which request exactly the same data, but use the different implementations. The queries are simple, they retrieve data from a table, and using hierarchical information generate a DTO with the data in a hierarchy.

The data in the database is along the lines of

------------------------
ID  | Description
----|-------------------
1   | Item 1
2   | Item 2
3   | Item 3
4   | Item 4
5   | Item 5

----------------
Parent | Child  
-------|--------
1      | 2
1      | 3
3      | 4
1      | 5

Desired Output
--------------
Item 1
|-Item 2
|-Item 3
| |-Item 4 
|-Item 5

And so the queries currently take the form of:

from a in tableA
join b in tableB on b.Parent equals a.ID
where b.Parent == root.ID
select new DTO.Entry {
  Id = a.ID
  ...
}

The method containing this query is run recursively until there are no more child elements left to process.

Using Linq-to-entity the test takes about 320ms to complete, using ADO.Net the tests takes about 8ms!

Is this just something I have to live with/consider or should the performance be about on par? Also, as the underlying data structure has no referential integrity (I know!), so I am compensating for this in my ADO.Net stuff, but I can't with Entities, is this likely to have an impact?

At the moment it seems that if you want performance then you should stick with ADO.Net

Upvotes: 0

Views: 907

Answers (1)

Gert Arnold
Gert Arnold

Reputation: 109080

Ask a customer: do you want more performance or less bugs?

Of course plain ADO.Net performs better than a data layer that also uses ADO.Net but before and after that does a lot more. Moreover, you chose an area where EF is not a good competitor when it comes to efficiency: recursive queries. But generally, when it comes to writing correct, stable code that performs acceptably, EF (or any seasoned OR mapper) rises head and shoulders above ADO.Net. It is hand-written SQL and data driven programming vs. linq and object oriented programming.

Nevertheless, you right when you say

At the moment it seems that if you want performance then you should stick with ADO.Net

Sure, for performance-critical operations OR mappers tend to have too much internal overhead to fit the bill. And to return to recursive queries: nothing beats recursive queries with CTE's in the database.

Upvotes: 2

Related Questions