LINQ Performance Pitfalls

Analogy categoryAnalogies

Why LINQ Can Be Deceptively Slow

LINQ's fluent, declarative syntax reads like plain English, which makes it easy to forget that every Where, Select, and OrderBy call allocates an iterator object and builds a pipeline that only runs when enumerated. Each stage adds a small but real cost in delegate invocation and enumerator state machines, and chaining many operators over large sequences can add up to noticeably more overhead than an equivalent hand-written for loop.

🏏

Cricket analogy: Just as a captain who calls for DRS review after DRS review adds up delay time even though each review is quick, chaining Where after Select after OrderBy adds small iterator overhead at every stage of the LINQ pipeline.

Multiple Enumeration of the Same Sequence

An IEnumerable<T> returned by a LINQ query is not a cached result; it is a recipe that reruns from the source every time it is enumerated. Calling .Count(), then a foreach loop, then .Any() on the same query variable executes the entire pipeline three separate times, which is wasteful for in-memory data and can trigger three separate database round trips when the source is an IQueryable backed by Entity Framework.

🏏

Cricket analogy: Asking the third umpire to re-review the exact same run-out replay three separate times instead of caching the verdict wastes match time, just as re-enumerating the same LINQ query three times reruns the entire pipeline each time.

N+1 Queries and IQueryable vs IEnumerable

When working with Entity Framework, calling .AsEnumerable() or .ToList() too early switches a query from IQueryable (translated to SQL) to IEnumerable (executed in memory), so subsequent filters run client-side instead of in the database. The opposite mistake, lazily accessing a navigation property inside a Select over an entity collection without eager loading via Include, produces an N+1 query pattern: one query for the parent rows plus one additional round trip per row for the related data.

🏏

Cricket analogy: A scorer who fetches the full ball-by-ball commentary for every single over separately instead of pulling the whole innings scorecard in one request wastes bandwidth, just like an N+1 query fetching related rows one at a time instead of one Include join.

Deferred Execution Traps

A LINQ query variable stores an unexecuted expression tree, not a snapshot of results, so if the underlying collection or a captured closure variable changes between the query's declaration and its enumeration, the results reflect the state at enumeration time, not declaration time. This is especially dangerous inside loops that build a list of queries with a captured loop variable, or when a query filters a List<T> that is modified before the foreach that consumes it runs.

🏏

Cricket analogy: A team sheet submitted before the toss that gets silently updated after an injury means the eleven printed on paper is not the eleven that actually walks out, just as a LINQ query's results reflect the source collection's state at enumeration, not declaration.

A classic bug: building a List<Func<int>> inside a for loop that closes over the loop variable, or filtering a List<T> with .Where(x => list.Contains(x)) and then removing items from list before enumerating the query, both silently change results because the query only captures a reference, not a value, until you force materialization with .ToList() or .ToArray().

csharp

// Pitfall: multiple enumeration + late materialization
IQueryable<Order> pending = db.Orders.Where(o => o.Status == "Pending");

// BAD: hits the database twice
int count = pending.Count();
var list = pending.ToList();

// GOOD: materialize once, reuse the in-memory list
var orders = db.Orders.Where(o => o.Status == "Pending").ToList();
int count2 = orders.Count;
var first10 = orders.Take(10).ToList();

// Pitfall: N+1 from a missing Include
var customers = db.Customers.ToList();
foreach (var c in customers)
{
    // Each access below issues a separate SQL query if lazy loading is on
    Console.WriteLine(c.Orders.Count);
}

// Fix: eager-load in one query
var customersWithOrders = db.Customers.Include(c => c.Orders).ToList();

Every LINQ operator in a chain allocates an iterator and adds small per-element overhead; long chains over large sequences add up.
IEnumerable<T> query variables are recipes, not cached results — enumerating them twice reruns the whole pipeline twice.
Call .ToList() or .ToArray() once to materialize a query you plan to use more than once, especially against a database.
Switching from IQueryable to IEnumerable too early (via AsEnumerable or premature ToList) moves filtering from SQL to in-memory code.
Accessing lazy-loaded navigation properties inside a loop causes N+1 queries; use .Include() to eager-load related data in one query.
Deferred execution means a query reflects the source's state at enumeration time, not declaration time — mutating the source in between changes results.
Materialize with .ToList() before mutating a source collection you're about to iterate a query over, to freeze the snapshot you intended.