LINQ Isn’t Slow

These LINQ Patterns Are

Viktor Ponamarev

8 min read

·

Aug 9, 2026

--

Listen

Share

A LINQ query can be harmless when it runs once over 100 items. The same query becomes expensive when Count() silently replays it, when First() performs a linear search inside another loop, or when a tiny pipeline is rebuilt thousands of times.

Press enter or click to view image in full size

The syntax didn’t suddenly get slower. The work crossed a repeated boundary.

That distinction matters. Replacing a nested First() with a manual inner loop preserves the same worst-case complexity. You’ve removed LINQ and kept the real problem.

This article is about in-memory LINQ to Objects through System.Linq.Enumerable, with .NET 10 and C# 14 as the primary environment. It does not cover IQueryable<T>, EF Core translation, PLINQ, or IAsyncEnumerable<T>—those have different execution models and deserve different performance rules.

An IEnumerable<T> query is a recipe, not a result

Consider this ordinary code:

IEnumerable<Order> eligible =
    orders.Where(o => o.Total >= minimum);

if (eligible.Count() > 0)
{
    LogCount(eligible.Count());
    foreach (var order in eligible)
        Process(order);
}

It looks as though eligible contains the filtered orders. Usually, it doesn’t. It contains the source and the operations required…