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().
// 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.
Practice what you learned
1. Why does calling .Count() and then .ToList() on the same IQueryable<Order> against Entity Framework cause two separate database round trips?
2. What causes an N+1 query problem when iterating over a list of Customer entities and accessing c.Orders inside the loop?
3. What is the main performance risk of chaining many LINQ operators like .Where().Select().OrderBy() over a large in-memory collection?
4. Why is mutating a List<T> after building a deferred LINQ query over it, but before enumerating the query, dangerous?
5. What does calling .AsEnumerable() on an IQueryable<T> in Entity Framework do to subsequent .Where() calls?
Was this page helpful?
You May Also Like
LINQ vs Loops
Compare LINQ's declarative query syntax against traditional for/foreach loops in terms of readability, composability, and raw performance.
LINQ with Large Datasets
Strategies for using LINQ efficiently over large in-memory and streamed datasets, including PLINQ, streaming, and memory management.
Debugging LINQ Queries
Practical techniques for stepping through, inspecting, and diagnosing bugs in LINQ query chains, including deferred execution pitfalls.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics