JIT Intrinsic Recognition and Unrolling for Common LINQ Patterns (Zero-Cost LINQ)

[Mortezamir81]

Description

LINQ is one of the most beloved features of C#, offering declarative and readable data manipulation. However, for high-performance scenarios, developers are often forced to abandon LINQ in favor of manual foreach or for loops to avoid allocation and virtual call overheads.

I propose that RyuJIT (utilizing Dynamic PGO) should be enhanced to recognize and optimize common LINQ patterns on standard collections (List<T>, T[], Span<T>), effectively treating them as intrinsics.

The Problem

Even with recent optimizations in System.Linq, using LINQ still incurs costs:

1. Allocations: Delegate allocations (unless static), closure allocations, and enumerator allocations.
2. Interface Dispatch: Iterating via IEnumerable<T> or IEnumerator<T> involves virtual/interface calls that block inlining.
3. Missed Vectorization: The JIT cannot easily vectorize a LINQ chain compared to a raw for loop.

Currently, "Clean Code" (using LINQ) is often at odds with "Performant Code".

Proposed Solution

With the advent of Dynamic PGO in .NET, the runtime has much more visibility into the actual types being executed. The proposal is to teach the JIT to recognize specific "hot" LINQ chains.

For example, consider this pattern:

int sum = myArray.Where(x => x > 0).Sum();

Instead of executing the standard Enumerable methods, the JIT could optimize this at runtime by:

1. Pattern Matching: Recognizing the .Where().Sum() chain on a generic T[].
2. Inlining & Unrolling: Generating code equivalent to a manual loop:

   // Concept of generated machine code
   int sum = 0;
   for (int i = 0; i < myArray.Length; i++) {
      if (myArray[i] > 0) sum += myArray[i];
   }

3. Vectorization: Applying SIMD optimizations to the generated loop.

Impact

This would be a massive "Quality of Life" improvement for the entire ecosystem:

• Zero-Cost Abstractions: Bringing C# LINQ performance closer to Rust Iterators or C++ Ranges.
• Performance: Immediate speedup for millions of existing lines of code without recompilation or refactoring.
• Simplification: Removal of "hand-optimized" loops in libraries, making the codebase more maintainable.

Feasibility

While extremely complex, the foundation is already laid out with Dynamic PGO and OSR (On-Stack Replacement). The JIT already performs Loop Cloning and GDV (Guarded Devirtualization). Extending this logic to recognize "Well-Known LINQ Methods" could be the next frontier in .NET optimization.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Proposal: Optimize LINQ to Objects code #4813

[huoyaoyuan]

See dotnet/csharplang#2482

[Mortezamir81]

Thanks for the link. I've read through #2482.

However, discussion #2482 focuses heavily on "Language Design" changes (e.g., struct enumerables, shapes, changing method signatures) which are hard to implement without breaking changes or complexity.

My proposal here is strictly about a "Runtime/JIT" optimization (Intrinsic Recognition via Dynamic PGO).
The goal is to optimize existing LINQ code patterns transparently, similar to how the runtime optimizes EqualityComparer<T>.Default, rather than introducing new language features.

[huoyaoyuan]

The goal is to optimize existing LINQ code patterns transparently

This is much harder than any optimizations ever. The JIT needs to link and transform control flows spread in several methods, with delegate inlining as a prerequisite. It's far different from EqualityComparer<T>.Default.

Intrinsic Recognition via Dynamic PGO

Intrinsic is not supported outside CoreLib. Dynamic PGO can only adjust weights, it can't bring new capabilities.

[neon-sunset]

FWIW take a look at https://github.com/Cysharp/ZLinq
It's not exactly what you are asking for but we've been using it in production quite successfully, especially in places which are ok with having to call delegates or can rely on JIT doing guarded devirtualization of such.