Entity Framework Is Slow. It's Not EF's Fault.

#dotnet #efcore #csharp #performance

Your API was quick in development. Then traffic picks up and a few endpoints start taking three seconds to respond.

You open the code, see Entity Framework everywhere, and figure that's the culprit. Time to rip it out and write proper SQL.

Don't. Before you throw away the thing saving you thousands of lines of code, look at what it's actually doing. Most of the time EF isn't slow. It's doing exactly what your code asked, and your code asked for something expensive.
EF Does What You Tell It

Entity Framework writes SQL for you. That's the point, and it's useful. The downside is that one clean-looking line of C# can turn into a query that hammers your database, and nothing in the code tells you that's happening.

The SQL is hidden, so the cost is hidden too. That's usually where things go wrong.

Below are the four things that actually slow EF down. None of them are EF being slow.
1. The N+1 Problem

This is the big one. Almost every slow EF app has it somewhere.

You load a list of orders, loop through them, and read order.Customer for each one:

var orders = context.Orders.ToList();
foreach (var order in orders)
{
    Console.WriteLine(order.Customer.Name);
}

EF didn't load the customers when it loaded the orders. So the first line runs one query, and then every time you touch order.Customer it goes back to the database for that one customer. A hundred orders, a hundred and one queries.

Tell EF to load the customers with the orders and the problem goes away:

var orders = context.Orders
    .Include(o => o.Customer)
    .ToList();

Same data on screen, one query instead of a hundred and one.
2. Loading Whole Entities for Two Fields

Say you need a list of customer names and emails for a page. The easy version:

var customers = context.Customers.ToList();

EF pulls every column of every customer and builds a full object for each. Addresses, notes, timestamps, everything. You needed a name and an email.

Project down to what you'll actually use:

var customers = context.Customers
    .Select(c => new { c.Name, c.Email })
    .ToList();

Now it's two columns. Less data read, less memory spent building objects you were never going to look at.

3. Tracking You Don't Need

EF tracks every entity it loads so it can figure out what changed when you call SaveChanges. That's needed when you're updating something. It's pure overhead when you're just reading data to show it on a screen and you'll never touch it again.

For read-only queries, switch tracking off:


var products = context.Products
    .AsNoTracking()
    .ToList();

On a large result set this matters, because EF stops building and holding all the change-tracking state it was never going to use.

Filtering in C# Instead of the Database

This one is easy to miss and it hurts badly:


var activeUsers = context.Users
    .ToList()
    .Where(u => u.IsActive);

The ToList() runs first. That pulls every user into memory, and only then does the Where filter them in C#. Two million users, fifty active, and you've loaded all two million to keep fifty.

Move the filter ahead of ToList() so it ends up in the SQL:

var activeUsers = context.Users
    .Where(u => u.IsActive)
    .ToList();

Now the database filters and hands you fifty rows. Same two lines, swapped order, completely different behaviour under load.
See What EF Is Doing

You don't have to guess about any of this. EF can log the SQL it generates. Turn it on in your DbContext setup:

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);

Run the app, hit the slow endpoint, read the output. The same SELECT firing over and over in a loop is your N+1. A query dragging out thirty columns when you needed two is your projection problem. It's all there.

Most teams never look. They treat EF as a black box and blame it when things get slow. It isn't a black box. The SQL is sitting in the logs the whole time.
When Raw SQL Is Actually Worth It

EF isn't always the right call. A heavy reporting query with several joins, grouping and aggregation can genuinely be faster and clearer as hand-written SQL or a stored procedure. Use raw SQL there. EF doesn't have to handle everything.

But that's a small part of a normal app. The everyday reads and writes that make up most of your code are fine in EF once you've stopped tripping over the four things above. Rewriting your whole data layer because a handful of queries are slow is a huge amount of work to fix something that usually lives in four or five places.

Find the slow queries first. Then decide.
Our Take

At Qodors, when a client says EF is slow and wants it gone, the first thing we ask for is the generated SQL. Nobody writes raw SQL until we've seen that.

It's almost always the same short list. An N+1 that needs an Include. A query loading full entities where a projection would do. Read-only queries that should be AsNoTracking. A filter sitting on the wrong side of a ToList(). Fixing those is usually a day of work, and it gets you most of the speed people were hoping a full rewrite would buy.

EF is a tool. Hand it careless code and it produces expensive queries. That's worth understanding before you decide the framework is the problem.
Before You Rip Out EF

Turn on SQL logging and read what EF actually generates
Look for the same query firing in a loop, then fix it with Include
Check whether you're loading full entities where a Select would do
Make sure read-only queries use AsNoTracking
Check for any .Where sitting after a .ToList() instead of before it

EF will happily generate bad SQL if your code asks for it. The fix is almost never ripping it out. Read the queries first. Most teams find the framework was never the problem.