Every mistake on this page compiles, and most of them look completely ordinary in a code review. That's exactly what makes them expensive in production.

This Part has taken you from how IEnumerable<T> and IQueryable<T> actually work, through building your own operators, to naming and understanding LINQ to Objects and LINQ to Entities as genuinely different providers with genuinely different execution models. Every one of those lessons taught you a tool used correctly. This lesson, closing out Part III, looks at the same territory from the opposite direction: the real performance mistakes developers make with these exact tools most often — mistakes that compile cleanly, often even run correctly in a small dev database or a quick local test, and only reveal their real cost once they hit production-scale data.

In this lesson, you'll walk through five real LINQ performance traps spanning both LINQ to Objects and LINQ to Entities — repeated enumeration of an un-materialized query, the N+1 query problem (the most damaging of the five, and treated in the most depth), pulling too much data into memory before filtering, missing AsNoTracking() on read-only EF Core queries, and unnecessary intermediate ToList() calls — see exactly why each one costs what it costs, and close with a concrete checklist for verifying a query's real cost instead of guessing.

What Is It?

The Simple Explanation

A "LINQ performance trap," in the sense used on this page, is code that looks completely reasonable — often even idiomatic — and produces correct results, but does meaningfully more work than the task actually requires: re-running a database query that didn't need to run again, issuing hundreds of small queries where one would do, pulling far more rows or columns across the wire than the final result actually needed, or tracking entities that were never going to be modified.

The Technical Definition

What unites all five traps below is that each one violates something this Part specifically established: that IQueryable<T> execution is deferred and re-runs on every materialization, that EF Core translates LINQ into real SQL with a real network round trip attached, that change tracking has a real per-entity cost, and that yield return-based operators stream rather than buffer. None of these are compiler errors — they're violations of an execution model you now understand in real depth, which is exactly what makes them worth a dedicated, curated tour rather than a vague "be careful" warning.

Why Does It Exist?

The Problem — LINQ Performance Bugs Rarely Look Like Bugs

A missing null check crashes loudly, right at the mistake. Most of these don't. A repeated foreach over the same IQueryable<T> variable returns perfectly correct data, every single time — it just quietly re-runs the whole query against the database each time, instead of once. A loop that queries per item works flawlessly against 10 test rows and only becomes visibly slow once a real dataset has thousands. These mistakes are dangerous precisely because they're invisible under the conditions most code review and casual local testing actually happens in.

The Solution — A Curated Tour, Grounded in What This Part Already Taught

The rest of this lesson is exactly that tour: five traps, each shown as suspicious-looking-fine code next to its fix, with the underlying "why" explained using the mechanics — deferred execution, expression tree translation, change tracking, streaming iterators — this Part built up lesson by lesson.

Big Picture

Notice the pattern: every one of these traces directly back to a mechanism you already understand correctly from earlier in this Part or from Intermediate. This lesson isn't introducing new concepts — it's teaching you to recognize when one of those mechanisms has quietly been misused.

Trap 1 — Multiple Enumeration of an Un-materialized Query

IQueryable<Product> query = context.Products
    .Where(p => p.Stock > 0);

int count = query.Count();       // hits the database
var first10 = query.Take(10).ToList(); // hits it AGAIN
bool any = query.Any();          // and AGAIN

List<Product> products = await context.Products
    .Where(p => p.Stock > 0)
    .ToListAsync();  // ONE round trip

int count = products.Count;
var first10 = products.Take(10).ToList();
bool any = products.Any();

Why it's dangerous: An IQueryable<T> is, as this Part established, a description of a query — not a stored result. Every single materializing call (.Count(), .Any(), .ToList(), a foreach) re-executes the entire query against the database from scratch, independently. The mistake version above hits the database three separate times for data that could have been fetched once. This gets worse, not better, in LINQ to Objects too: an un-materialized IEnumerable<T> built with yield return re-runs its iterator logic on every enumeration as well — if that iterator does expensive work (parsing, computing, calling an external API), each enumeration pays that cost again.

The fix is always the same shape: materialize once, deliberately, into a concrete collection (List<T>, an array) the moment you know you'll need the results more than once — then work against that concrete collection with ordinary LINQ to Objects for anything further.

Trap 2 — The N+1 Query Problem

This is, without real competition, the most common and most damaging real-world EF Core performance bug — worth the most depth of anything in this lesson.

List<Order> orders = await context.Orders
    .ToListAsync();                     // query #1

foreach (var order in orders)
{
    // this line runs the Customer's navigation
    // property lazily — ONE query PER order
    Console.WriteLine(order.Customer!.Name);
}
// 1 order-list query + N customer queries = N+1 total

List<Order> orders = await context.Orders
    .Include(o => o.Customer)   // ONE query,
    .ToListAsync();             // with a JOIN

foreach (var order in orders)
    Console.WriteLine(order.Customer!.Name);
// 1 query total, ever — regardless of order count

Why it's dangerous: "N+1" means exactly what it sounds like: 1 query to fetch a list of N items, plus N further queries — one per item — to fetch each item's related data. With 10 orders, that's 11 total round trips to the database instead of 1. With 10,000 orders in production, it's 10,001 — each one a separate network round trip, separate SQL parsing and execution, separate connection-pool churn. A page that felt instant against 20 test rows in development can take tens of seconds — or simply time out — against a realistic production dataset, and the code causing it looks completely unremarkable in review: just a foreach loop reading a property.

The fix, as shown above, is .Include(...) — eager loading the related data as part of the original query, translated into a single SQL JOIN, exactly the navigation-property-to-JOIN pattern from the previous lesson. For projections that only need a few related fields rather than whole related entities, a single well-shaped Select(...) projecting across the navigation property (still one query, one join) is often even better than Include, since it also narrows the columns fetched:

The one thing every fix shares: N+1 is solved by reshaping the query to fetch everything in a single round trip — never by trying to make each of the N individual queries faster.

Trap 3 — Pulling More Data Into Memory Than the Task Needs

List<Product> all = await context.Products
    .ToListAsync();     // EVERY row, EVERY column

var cheap = all
    .Where(p => p.Price < 20)
    .Select(p => p.Name)
    .ToList();

List<string> cheap = await context.Products
    .Where(p => p.Price < 20)  // narrows rows
    .Select(p => p.Name)       // narrows columns
    .ToListAsync();            // THEN materialize

Why it's dangerous: Calling .ToListAsync() before filtering — as the mistake version does — pulls every column of every row across the network, only to immediately throw most of it away in C#. This is exactly the "client-side vs. server-side evaluation" distinction from earlier in this Part: filtering and projecting before materializing keeps the work inside the translatable IQueryable<T> chain, where EF Core turns it into a narrow WHERE and a narrow SELECT column list — real work the database does efficiently, often using an index. Filtering and projecting after materializing means every one of those savings is thrown away, and the full, unfiltered table crosses the wire regardless.

The rule of thumb: keep .Where(...) and .Select(...) as far "left" in the query chain as possible — as close to the DbSet<T> as the logic allows — and materialize only once, as the very last step.

Trap 4 — Missing AsNoTracking() on a Read-Only Query

[HttpGet]
public async Task<IActionResult> GetAll()
{
    // returned as read-only JSON — SaveChanges()
    // is never going to be called on these
    var products = await context.Products
        .ToListAsync();  // tracked, by default

    return Ok(products);
}

[HttpGet]
public async Task<IActionResult> GetAll()
{
    var products = await context.Products
        .AsNoTracking()   // skip snapshotting
        .ToListAsync();

    return Ok(products);
}

Why it's dangerous: As the Intermediate tracking-vs-no-tracking lesson covered in depth, every tracked entity costs a snapshot of its original values plus an entry in the change tracker — real memory and real CPU work, paid on every single request, for bookkeeping that only ever pays off if SaveChanges() is later called on that entity. A read-only listing endpoint that never calls SaveChanges() pays that cost on every request, forever, for zero benefit. It's individually a small cost per entity — but multiplied across every request, on a high-traffic read endpoint, it's a real, measurable, entirely avoidable tax.

The rule from that earlier lesson still applies exactly here: ask, per query, "will anything this query returns be modified and saved?" If the honest answer is no, .AsNoTracking() is free performance with no downside.

Trap 5 — Unnecessary Intermediate ToList() Calls Breaking Composition

var step1 = context.Products
    .Where(p => p.Stock > 0)
    .ToList();               // materializes HERE

var step2 = step1
    .Where(p => p.Price < 50)  // now LINQ to Objects —
    .ToList();                 // the second filter never
                                // reaches the database at all

List<Product> results = await context.Products
    .Where(p => p.Stock > 0)
    .Where(p => p.Price < 50)
    .ToListAsync();  // BOTH filters translate to SQL,
                     // ONE round trip, ONE narrowed result

Why it's dangerous: An intermediate .ToList() in the middle of a query chain does two costly things at once: it forces materialization earlier than necessary (an unfiltered-so-far result crosses the network), and it silently switches every operator chained afterward from LINQ to Entities to LINQ to Objects — the second .Where(...) above never becomes SQL at all; it runs in memory, against data that should have been filtered by the database in the first place. This is the mirror image of Trap 3: composing filters and projections into one continuous IQueryable<T> chain, and materializing only once at the very end, lets EF Core see and translate the whole query together — often more efficiently than the sum of two separate round trips ever could be.

Analogy

Under the Hood — How to Actually Verify a Query's Real Cost

Common Confusion

1. "N+1 only matters for huge datasets"

It's most visible at scale, but the extra round trips exist even for a small N — they're just fast enough, individually, to go unnoticed. The real danger is that N+1 code passes review and passes casual testing precisely because small-scale symptoms are mild; the underlying shape of the query (one per item, in a loop) is the actual defect, regardless of how many items happen to be in the loop today. Data grows; the code causing N+1 usually doesn't get revisited until it already hurts.

2. "AsNoTracking() and repeated enumeration are unrelated concerns"

They compound. A tracked query that's also enumerated multiple times pays the full snapshot-and-tracking cost again on every re-enumeration — each fresh call to .ToListAsync() against the same un-materialized IQueryable<T> both re-runs the SQL and re-creates tracking entries for every returned row. Fixing either trap alone helps; recognizing that these traps stack is what separates a merely-acceptable fix from a genuinely well-optimized query.

When Should I Use This Checklist?

Mental Model

Key Takeaway

Check Your Understanding

You've toured five real production LINQ performance traps, and how to actually verify a query's cost instead of guessing. Let's confirm the reasoning stuck — this is Part III's final check.

You've completed Part III — LINQ Deep Dive. You can now design real custom LINQ operators, speak precisely about LINQ to Objects versus LINQ to Entities, explain EF Core's translation pipeline and its real edges, read LINQ and predict the SQL underneath it, and — critically — recognize the production performance traps that catch even experienced teams off guard. That's the whole arc, from mechanics to mastery.

dotnetmadeeasy.com — Learn C# and .NET, the right way.