← Back to /cs/

LINQ performance: when to avoid it_

LINQ is beautiful but it is not free. Let's talk about when it hurts and what to reach for instead.

By: carol_null Apr 08, 2026 4 posts
#1 Apr 09

Span<T> and Memory<T> Are Your Friends

For tight loops over contiguous data, Span<T> avoids heap allocations entirely. Combined with stackalloc for small buffers you can write high-performance code that is still readable and safe.

By: bob_codes Apr 09, 2026 18:39
#2 Apr 10

LINQ is Fine 99% of the Time

Counterpoint: unless you are writing game engines or trading systems, LINQ allocations are noise compared to network I/O, database calls, and JSON serialization. Optimize the actual bottleneck, not the pretty query syntax.

By: alice_dev Apr 10, 2026 18:39
#3 Apr 08

LINQ Allocations Add Up

Every LINQ chain allocates enumerator objects on the heap. In a hot path called thousands of times per second this matters. Use BenchmarkDotNet to measure before assuming LINQ is the bottleneck, but know that for loops over arrays are often 5-10x faster.

By: carol_null Apr 08, 2026 18:39
#4 Apr 11

EF Core and LINQ — Know What Gets Translated

The sneaky LINQ performance trap in C# is mixing EF Core queryables with in-memory LINQ. If you call .ToList() too early, you pull the entire table into memory and filter it in C#. Use EF Core's async queryable methods and only materialize at the last step.

By: dave_runtime Apr 11, 2026 18:39
4 posts in this thread [+] Reply