Entity Framework is inefficient. What are my alternatives?

.net entity-framework orm performance


The "Don't Optimize Prematurely" maxim guided my use of Entity Framework while coding my WCF Service.

I did a performance profile, however, and Entity Framework is too sluggish. (My app processes 2 messages in roughly 1.2 seconds, compared to 5–6 messages processed in the same amount of time by the (old) program I'm rewriting. (The older app uses sprocs to access its DB.)

According to my profiling, Entity Framework consumes the majority of the time for each message.

What are my choices, then?

  • Exist any better ORMs today?
    (Something that just facilitates quick reading and writing of items.)

  • Is Entity Framework capable of being made faster?
    (Zzz-35-Zzz: When I say faster, I don't just mean on the initial call; I mean faster overall. Although the first call is sluggish (15 seconds for a message), nothing is wrong. For the remaining communications, I just need it to be quick.)

  • I have a third, unidentified option that will enable me use my service more quickly.

NOTE: I mostly interact with the database using Create and Update. I seldom ever select or delete anything.

7/19/2018 4:15:50 PM

Accepted Answer

Profiling the SQL instructions that the Entity Framework really issues should be your first step. There is a lot of possibility for improvement depending on your setup (POCO, Self-Tracking entities). The SQL instructions (which shouldn't vary between debug and release mode) may be investigated using theObjectSet<T>.ToTraceString() method. If you come across a query that needs additional optimization, you may use some projections to explain to EF what you're attempting to achieve.


Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
    dto.Categories.Add(new CategoryDto { Name = category.Name });

It could be changed to:

var query = from p in db.Products
            where p.Id == 10
            select new
                Categories = from c in p.Categories select c.Name
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
    dto.Categories.Add(new CategoryDto { Name = categoryName });

If you give EF all you know about the query, it actually does some great improvements. However, I simply wrote that out of my mind, so that isn't precisely how it would be carried out (in this case, that we will need the category-names). However, projections might further minimize the amount of data to load, unlike eager loading (db.Products.Include("Categories")).

12/1/2011 8:34:18 PM

Popular Answer

The reality is that since they are running a lot more code, technologies like Entity Framework will ALWAYS be sluggish and inefficient.

I also think it's ridiculous when folks advise optimizing LINQ queries, looking at the resulting SQL, using debuggers, pre-compiling, etc. that is, lose a lot of time. Nobody tells you to "simplify" Everyone wants to comlicate things further by taking even more steps (wasting time).

The obvious course of action would be to never utilize EF or LINQ. Use simple SQL. Nothing is wrong with it. Programmers tend to have a herd mentality and feel compelled to utilize every new product that comes out, but this does not always indicate that the product is excellent or that it will work. Most programmers believe that by incorporating each new piece of code that a major corporation releases, they become wiser programmers, however this is not true at all. The main focus of smart programming is on finding ways to do more with fewer hassles, uncertainties, and delays. Recall: Time! The most crucial component, thus try to avoid wasting time on fixing issues in poor or bloated code that was built just to follow oddly named "patterns."

Take a vacation from coding, unwind, and cease using more features, code, goods, and "patterns." It's hardly rocket science, but life is short and your code's lifespan is even shorter. Your code will scale well, run well without layers like LINQ and EF, and yes, it will still be simple to maintain. A terrible "pattern" is one with excessive abstraction.

The answer to your issue is that.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow