Zero-Allocation Programming in C#: Span, Pools, stackalloc

Every tool in this Part has been a piece of the same puzzle. This lesson is where the pieces click together.

Look back at what this Part has handed you so far: Span<T> and ReadOnlySpan<T> to slice data without copying it, Memory<T> to carry a view across async boundaries, ArrayPool<T> and MemoryPool<T> to reuse buffers instead of allocating fresh ones, ref/in parameters to avoid copying large structs, readonly struct from Advanced Part I to avoid defensive copies, ref struct to guarantee it's all memory-safe, and stackalloc for small bounded buffers that never touch the heap at all. Individually, each one solved a specific, narrow problem. Together, they form a coherent style of writing C# — and that style has a name.

In this lesson, you'll see what "zero-allocation" (or "low-allocation") programming actually means in practice, watch a realistic hot-path rewrite that uses this Part's toolkit end to end, and — just as importantly — learn exactly when this style is worth the cost it demands, and when it very much isn't.

What Is It?

The Simple Explanation

Zero-allocation programming means deliberately writing a specific piece of code — usually one method or one tight loop, never "the whole app" — so that it allocates little or nothing on the managed heap while it runs. Low-allocation is the more honest, more common cousin: not literally zero, but dramatically fewer allocations than the naive version, on a path where that difference actually matters.

The Technical Definition

Concretely, it means minimizing managed heap allocations — new on a reference type, boxing a value type, an intermediate string, a LINQ operator's iterator object, a closure — on a specific hot path, in order to reduce the amount of work the garbage collector has to do because of that path. Tying this directly back to Advanced Part I's GC lessons: fewer allocations means fewer objects entering Gen0, which means Gen0 fills up more slowly, which means fewer collections overall, and (for anything that happens to survive) less pressure pushing objects into the more expensive Gen1 and Gen2 collections. Zero-allocation programming isn't a separate technique from what you've already learned about the GC — it's the direct, practical application of that knowledge to writing code.

Why Does It Exist?

The Problem

Modern .NET's generational GC (Advanced Part I) is genuinely excellent at handling ordinary allocation rates — Gen0 collections are fast, and most applications never think about this at all, correctly. But on a path that runs extremely frequently — a per-request hot loop in a high-throughput API, a per-frame update in a game, a per-message parse in a trading system or log pipeline — even small allocations add up to a real, measurable cost: more frequent Gen0 collections, more objects surviving into more expensive generations, and — in latency-sensitive systems — GC pauses landing at genuinely inconvenient moments. Advanced Part IV's high-throughput async lesson already touched on exactly this concern for async code specifically; this lesson generalizes it.

The Solution

Every tool this Part has introduced exists to let you do real work — slicing strings, passing data around, building buffers — without the default "allocate a new heap object for this" behavior that ordinary, idiomatic C# reaches for by default. None of them are new capabilities in the sense of doing something previously impossible; they're all ways of doing the same work with a different, more deliberate memory strategy, reserved for the specific paths where the default strategy's cost is actually a proven problem.

Big Picture — the toolkit, assembled

How It Works — before and after, a log-line parser

Here's a plausible, ordinary hot path: parsing a structured log line like 2026-08-31T10:15:00Z|WARN|OrderService|Order 4821 exceeded retry limit into its four fields, called on every single incoming log line in a high-throughput service.

Before — the natural, idiomatic, allocation-heavy version

public record LogEntry(string Timestamp, string Level, string Source, string Message);

public static LogEntry ParseLogLine(string line)
{
    string[] parts = line.Split('|');       // allocates a string[] AND four new strings
    return new LogEntry(
        parts[0],
        parts[1],
        parts[2],
        parts[3]);                          // 'Message' — one more implicit allocation if it needed trimming
}

Every single call allocates: the string[] array from Split, each of the four substrings Split creates internally, and the LogEntry record itself. For a service processing tens of thousands of log lines per second, this is a steady, significant stream of small, short-lived Gen0 garbage — exactly the pattern the Generational GC lesson described as cheap individually, but not free in aggregate.

After — rewritten with this Part's toolkit

public readonly ref struct LogEntryView
{
    public ReadOnlySpan<char> Timestamp { get; }
    public ReadOnlySpan<char> Level { get; }
    public ReadOnlySpan<char> Source { get; }
    public ReadOnlySpan<char> Message { get; }

    public LogEntryView(ReadOnlySpan<char> timestamp, ReadOnlySpan<char> level,
                         ReadOnlySpan<char> source, ReadOnlySpan<char> message)
    {
        Timestamp = timestamp;
        Level = level;
        Source = source;
        Message = message;
    }
}

public static LogEntryView ParseLogLine(ReadOnlySpan<char> line)
{
    Span<Range> fieldRanges = stackalloc Range[4]; // tiny, fixed, bounded — safe per lesson 230
    int found = 0;
    int start = 0;

    for (int i = 0; i < line.Length && found < 4; i++)
    {
        if (line[i] == '|')
        {
            fieldRanges[found++] = start..i;
            start = i + 1;
        }
    }
    if (found == 3)
        fieldRanges[found++] = start..line.Length;

    return new LogEntryView(
        line[fieldRanges[0]],
        line[fieldRanges[1]],
        line[fieldRanges[2]],
        line[fieldRanges[3]]);
}

What changed, and why it matters:

• ReadOnlySpan<char> in and out — slicing line produces views into the original memory, never new heap strings.
• A small, fixed-size Span<Range> fieldRanges = stackalloc Range[4] replaces the heap-allocated string[] from Split — four is a known, bounded count, so this is exactly the safe pattern from the previous lesson.
• LogEntryView is a readonly ref struct — readonly because none of its span fields ever change after construction (avoiding defensive copies wherever it's passed by in), and ref struct because it holds span fields at all, which per lesson 229 is only legal inside a ref struct.
• This version allocates nothing on the heap for the parse itself — not the array, not the four field strings, not even the returned "record," since LogEntryView is a stack-only value type.
• The trade-off, visible immediately: LogEntryView inherits every ref struct restriction — it can't be stored in a field, put in a List<LogEntryView>, or held across an await. A caller that genuinely needs to keep a parsed entry around calls .ToString() on the fields it actually needs, at the point it needs them — converting a few of the four spans to real strings, rather than all four by default.

Real-World Example — this exact pattern in the BCL and popular libraries

This isn't a contrived teaching example — it's the same design pattern behind real, widely-used .NET code. System.Text.Json's Utf8JsonReader is a ref struct that walks JSON text as spans, without allocating strings for tokens it doesn't need materialized. High-performance HTTP header parsers in ASP.NET Core's Kestrel server use ReadOnlySpan<byte> extensively for exactly this reason — a server handling tens of thousands of requests per second cannot afford a fresh string allocation for every header on every request. The log-parser example above is a smaller-scale version of precisely the same reasoning these production systems apply at massive scale.

Analogy

Under the Hood — why this actually reduces GC pauses, not just allocation counts

Common Confusion

1. "Zero-allocation means literally zero allocations, everywhere in the app"

No — it means zero (or dramatically fewer) allocations on one specific, deliberately targeted hot path. The rest of the same application — startup code, configuration loading, admin endpoints hit once a minute — has no reason to adopt this style at all, and shouldn't.

2. "This is a totally new set of skills, unrelated to what I already know about the GC"

Not at all — this lesson is the direct application of the Generational GC lesson's mental model. If you understand why Gen0 pressure matters, you already understand why this style helps; this lesson mainly supplied the how.

3. "If it's available, I should just always write code this way"

This is the single most important misconception to avoid, and it gets its own full section next — see When Should I Use It? below.

Common Mistakes

Mistake 1 — Applying this style to code that isn't actually a hot path

Rewriting a configuration parser that runs once at startup into a ref struct-and-stackalloc version, because it "seemed like good practice."

Save this toolkit for paths that run often enough for allocation count to matter in aggregate — the next lesson gives you the tool to actually confirm that, rather than assuming it.

Mistake 2 — Rewriting for zero allocation without measuring the before-and-after

Assuming the rewrite helped because it "should" — the intermediate representation might still box somewhere, or a small allocation might have been genuinely negligible next to a much larger, unrelated cost elsewhere in the same request.

Verify allocation reduction directly, rather than trusting intuition — exactly the subject of the next lesson.

Mistake 3 — Letting a low-allocation type leak into the rest of the codebase's API surface

Making a public API return a ref struct view type like LogEntryView when most callers just want an ordinary, storable LogEntry they can put in a list or pass to another service — forcing every caller to deal with ref struct restrictions they don't need.

Keep the zero-allocation representation as an internal implementation detail of the hot path itself; convert to an ordinary, storable type at the boundary where the data needs to travel further or persist.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen this Part's toolkit assembled into one coherent style. Let's confirm you understand both how it works and when to reach for it.

You've seen this Part's whole toolkit work together on a realistic example — and learned exactly when to reach for it. Next: how to actually prove a path is hot enough to deserve this treatment, instead of guessing.