.NET Linq? ZLinq

ZLinq v1 was released last month (April 2025). It already has more than 2,000 GitHub stars. ZLinq removes the long-standing compromise between LINQ's syntax and the speed demanded by high-performance .NET workloads. Traditional LINQ incurs heap allocations that turn into bottlenecks in tight loops, forcing many teams to abandon it. By eliminating those allocations, ZLinq makes it ideal for scenarios where every microsecond (and allocation) counts. It also breathes new life into legacy projects trapped on older .NET Framework versions.

Ideal Use Cases

ZLinq shines across multiple high-performance scenarios:

Data Processing

• Image processing and signal analysis
• Low-latency finance engines
• Numeric-heavy libraries

High-Throughput Services

• Real-time analytics
• JSON/XML tokenization
• Network-packet parsing

Legacy Projects

• Projects stuck on older .NET Framework versions
• Any scenario requiring allocation-free performance

Game Development

• Unity and Godot projects
• Collision checks, ECS queries, per-frame stats
• Real-time game engines

Core Purpose: Zero-Allocation & Speed

ZLinq is a new .NET-compatible library. It's a drop-in replacement for classic LINQ that delivers zero allocations, lower GC pressure, and noticeably higher throughput on every supported .NET platform.

What Makes It Different?

ZLinq rewrites the entire LINQ query pipeline to use value-type structs and generics instead of reference-type enumerator objects. Because structs live on the stack, each operator in a query (e.g., Where().Take().Select()) adds zero managed-heap allocations. Classic LINQ creates at least one heap object per operator, so allocations grow with every link in a query chain.

Performance Benefits

With the per-operator allocations gone, memory pressure stays flat and CPU cache usage improves. In normal workloads ZLinq is faster than classic LINQ, and in allocation-heavy scenarios (like nesting lots of Select calls) the speed gap becomes dramatic. Even operators that need temporary storage (Distinct, OrderBy, etc.) are quicker because ZLinq aggressively rents and re-uses arrays instead of creating new ones.

Because every operator is implemented with value-type enumerators, ZLinq avoids the heap allocations that ordinary LINQ incurs with each iterator hop. It also layers in Span support, SIMD acceleration, aggressive pooling for buffering operators like Distinct/OrderBy, and the same chain-flattening optimizations Microsoft added to LINQ in .NET 9 - so most real-world queries run faster while producing zero garbage.

The usual trade-off—readability versus speed—shrinks dramatically. You start by writing the clear query; add .AsVectorizable() or target Span and you're often done. Because it's still LINQ, existing analyzers, tests, and team conventions keep working. No custom DSLs to learn or legacy helpers to maintain.

Complete API Coverage & Compatibility

ZLinq reproduces 100% of the public LINQ surface that ships with .NET 10, including the newest operators such as Shuffle, RightJoin, and LeftJoin, plus every overload that was added in the latest framework release. It also back-ports every operator-chain optimization that's coming in .NET 9 - so you can get those advancements even on older targets like .NET Framework 4.x.

Anything you can call today on Enumerable (or on query syntax) also exists on ZLinq's ValueEnumerable. To ensure it really acts like the reference implementation, the authors ported ~9,000 unit tests from the dotnet/runtime repo. More than 99% run unchanged. The handful that are skipped rely on ref-struct patterns the new type system intentionally avoids. In day-to-day code you should see identical results.

Zero-Friction Adoption

You can opt-in by adding one Roslyn source-generator attribute that rewrites System.Linq calls to ZLinq at build time. If you'd rather be explicit, drop a single AsValueEnumerable() call at the start of your chain. Either way, existing projects compile and run without edits - just markedly faster and allocation-free.

Start with .AsValueEnumerable() in the one hotspot you're profiling - remove it if the gain isn't worth it. No large-scale refactor required. Start with the one-liner, then turn on the source generator for the whole solution when the team is comfortable. If the generator or the value pipeline hits an unsupported type, the call just resolves to the regular LINQ overload - so behaviour stays correct even on legacy runtimes.

Architecture and Internal Design

Classic System.Linq is allocation-heavy because each operator instantiates a heap iterator, hurting latency, cache locality, and GC in hot loops. ZLinq instead represents the entire query as a stack-allocated ValueEnumerable, swapping in a new enumerator struct at each stage. One streamlined iteration method plus optional fast-path hooks delivers LINQ's expressiveness with hand-written-loop performance.

Single "vessel" type

Everything in the query pipeline is wrapped in one ref struct, "ValueEnumerable". Each time you add an operator (Where, Select, etc.) the library just swaps in a new enumerator struct as the first type parameter.

One iterator primitive

 Instead of the usual pair "bool MoveNext() / T Current", enumeration is reduced to a single method "bool TryGetNext(out T current);". That halves the call count during iteration and lets each enumerator drop a field, trimming size and improving inlining.

Fast-path hooks

The optional methods on IValueEnumerator (TryGetNonEnumeratedCount, TryGetSpan, TryCopyTo) let an operator skip the element-by-element walk when it can provide the length up-front, expose a contiguous Span, or copy directly into a destination buffer.

Trade-off: you give up interface variance and use a value-centric API, but gain smaller code, predictable JIT behavior, and near-zero garbage.

Platform and Language-Version Support

ZLinq is for any project that can run .NET Standard 2.0 or newer - from the legacy .NET Framework through .NET 5-8 and game engines such as Unity (Mono) and Godot.

The headline feature is "LINQ to Span / ReadOnlySpan" - i.e. you can chain Where, Select, etc. directly on stack-allocated spans with zero boxing or copying. That trick becomes possible only when the upcoming C# 13 / .NET 9 adds the new allows ref struct generic constraint, so the full Span experience lights up there.

The same NuGet package works untouched in Unity projects that are stuck on older Roslyn versions. Only the Span-specific perks are gated to .NET 9+.

Specialized Extensions Shipped with v1

Memory-tight loops with Span 

Every built-in LINQ operator (Where, Select, Sum, etc.) can now run directly on Span / ReadOnlySpan rather than forcing you back to arrays or IEnumerable.

Transparent SIMD acceleration 

Under the hood, kernels that use Vector kick in for common numeric ops (Sum, Average, Min, Max, Contains, SequenceEqual, etc.). A special SumUnchecked drops overflow checks when you guarantee safety.

Intent signalling with .AsVectorizable() 

A one-liner that says "please switch to the SIMD plan if possible."

Unified traversal of hierarchical data 

ITraverser plus helpers like Ancestors, Descendants, BeforeSelf, etc., work on any tree: file-systems, JsonNode, Unity Transforms, Godot Nodes…

Older CPUs or AOT targets that lack SIMD simply get the scalar fallback. Your binaries remain single-build and portable.

Differences, Caveats & Limitations

There are four ways in which ZLinq's behavior can diverge from the classic library, listed in the order you're most likely to notice them. ZLinq shines when your query is short-lived, stays on the stack, does its math unchecked, and avoids captured variables.

Enumeration semantics 

For 99% of queries the two libraries step through a sequence the same way, but exotic cases (custom iterators, deferred side-effects) can yield a different element-by-element evaluation order in ZLinq.

Numeric aggregation 

ZLinq's Sum is unchecked—integer overflow wraps around silently—whereas System.Linq.Sum throws an OverflowException. ZLinq offers SumChecked if you want the safer behavior.

Pipeline lifetime rules 

ZLinq pipelines are built from ref struct iterators, which must stay on the stack. You can't stash an in-flight query in a field, capture it in a closure, or return it from a method.

Closure allocations 

ZLinq removes most internal allocations, but any lambda that captures outer variables still allocates a closure object - just like in standard LINQ. To stay allocation-free you must use static lambdas (new in C# 11) or refactor to avoid captures altogether.

Benefits, Risks & Warnings

ZLinq's cross-platform reach (Unity, Godot, .NET 8/9, Standard 2.0) is a strong practical advantage. Some teams still avoid LINQ in hot paths due to allocator costs - they welcome libraries such as ZLinq.

Benchmarks are published and run automatically on GitHub Actions - they indicate ZLinq wins "in most practical scenarios". Where ZLinq cannot beat classic LINQ, the limitation is structural (like unavoidable extra copies).

Lambda-capture allocations remain an important bottleneck which ZLinq does not itself solve. Other developers claim that removing LINQ usually yields negligible gains and harms readability. Concerns are voiced that adopting a third-party LINQ "replacement" might risk long-term maintenance, although ZLinq currently passes the full dotnet/runtime test-suite.

Some point out subtle incompatibilities (iteration order, checked arithmetic) that developers must be aware of when switching from the built-in System.Linq implementation to ZLinq.

The author stresses that issue/PR turnaround will sometimes be slow owing to limited bandwidth.

If You Need Zero-Allocation Behavior Today

.NET is getting better at avoiding waste. When your code uses lambdas or LINQ, the runtime used to create little objects on the heap. Starting with .NET 9, if a lambda doesn't capture any outside variables, that temporary object can now live on the stack instead of the heap.

The .NET 10 team is experimenting with similar tricks for the Where, Select, etc. objects that LINQ builds under the hood. If it works, a normal LINQ pipeline like source.Where(f).Select(g) could run without creating any heap objects.

You don't have to wait if you're in a hurry: Libraries such as ZLinq already deliver "no-allocation LINQ" today, and they plug in without changing your query syntax.

How Belitsoft Can Help

Whether you need to build a green-field product, revive a legacy .NET estate, squeeze out more performance, or expand capacity with vetted engineers, Belitsoft supplies the skills, processes, and industry insight to make your .NET initiative succeed - end to end, and future-proof.

For enterprises that need new business-critical software, Belitsoft offers end-to-end custom .NET development on ASP.NET Core and the wider .NET ecosystem —from discovery to post-launch support.

For companies stuck on aging .NET Framework apps, our engineers modernize and migrate to .NET Core / .NET 8+ through incremental steps (code audit → architecture redesign → database tuning → phased rollout).

For organizations moving workloads to the cloud (Azure / AWS), Belitsoft provides cloud-native .NET engineering and DevOps (container-ready builds, IaC, CI/CD) plus cloud-migration assessments and post-migration performance monitoring.

For teams that work under performance & scalability pressure (high-load APIs, fintech, IoT), we deliver deep .NET performance optimization—profiling, GC-pressure fixes, architecture tweaks, load testing, and continuous performance gates in CI.

For product owners who put quality first, Belitsoft runs a QA & Testing Center of Excellence, embedding automated and manual tests (unit, API, UI, performance, security) into every .NET delivery flow.

For companies that must scale teams fast, we supply dedicated .NET developers or cross-functional squads that plug into your process, boosting velocity while cutting staffing costs.

For domain-specific verticals - Healthcare, Finance, eLearning, Manufacturing, Logistics - Belitsoft pairs senior .NET engineers with industry SMEs to deliver compliance-ready solutions (HIPAA, PCI DSS, SCORM, etc.) on proven reference architectures.