Stack vs Heap in C#: Stop Wasting Memory

Stop guessing where your C# memory goes. In one of my APIs I cut GC time by 72% and dropped p95 latency by 38 ms just by moving three hot paths off the heap. In this post you’ll see the same moves: clear rules, code you can ship, and hard numbers from real profiling runs.

Why It Matters (The Truth in 60 Seconds)

If your app sprays tiny allocations, you pay with CPU, GC pauses, and cloud cash. Here’s what you’ll get today:

• Master stack vs heap with focused rules and code you can ship.
• Kill boxing, chatty LINQ, and closure allocations in hot loops.
• See the GC impact in numbers: Alloc/Op, Gen 0/sec, Gen 2 time.
• Run BenchmarkDotNet to prove gains, then confirm in a profiler.
• Leave with a copy‑paste checklist for daily use.

The Truth: small, short‑lived data stays near the CPU (stack or stack‑like APIs). Shared or variable‑life data goes on the heap. Choose on purpose.

The short map: stack vs heap in .NET

Stack

• Stores locals and parameters for the current method frame.
• Very fast push/pop; lifetime is tied to scope.
• No GC work for stack memory.
• You can also allocate raw buffers on the stack with stackalloc.

Heap

• Stores reference types (classes, arrays, delegates, strings) and boxed values.
• Managed by the GC (Gen 0/1/2, plus LOH for big objects; POH for pinned ones).
• Object lifetime is dynamic; GC pauses and copies add overhead.

Value vs reference types

• struct (value type): lives where it’s declared – on the stack if it’s a local, inside a heap object if it’s a field, or inline inside an array of that struct.
• class (reference type): the reference (pointer) lives on the stack or inside another object; the object lives on the heap.

A quick rule I use on teams: Use struct for tiny, immutable, copy-cheap data (coords, small IDs, simple math), use class for identity and sharing (entities, services, graphs).

GC in 90 seconds (just enough to act)

• Gen 0: youngest; frequent collections; cheap. Most short‑lived junk dies here.
• Gen 1: middle; used as a buffer between Gen 0 and Gen 2.
• Gen 2: long‑lived; fewer collections; more expensive to scan.
• LOH (Large Object Heap): arrays/strings typically ≥ ~85 KB; collected with Gen 2; movement is limited to keep big blocks stable.
• POH (Pinned Object Heap): for pinned buffers; reduces heap fragmentation.

Key signal: if Gen 0 allocations per second are sky‑high, your code is spraying tiny objects. If Gen 2 time is high, you keep objects alive too long.

The Truth about “stack is always faster”

Yes, stack access is fast, but the real win is avoiding GC pressure in hot loops. If you allocate a small object once per request, that’s fine. If you allocate one inside a 10M-iteration loop, you just bought a GC party.

Let’s make this concrete with code.

Real code #1 – Boxing: the sneaky heap hit

public interface IValueSink { void Add(object value); }

// Innocent looking:
void LogIntegers(IValueSink sink, int[] values)
{
    for (int i = 0; i < values.Length; i++)
    {
        sink.Add(values[i]); // boxing int -> object on every call
    }
}

Each int becomes an object on the heap. In a busy service this single line can allocate hundreds of MB per minute.

Fix it by making the sink generic and keeping values unboxed:

public interface IValueSink<T> { void Add(T value); }

void LogIntegers(IValueSink<int> sink, int[] values)
{
    for (int i = 0; i < values.Length; i++)
        sink.Add(values[i]); // no boxing
}

If you must keep the non-generic API, push batches and reuse buffers:

public interface IValueSink { void AddRange(ReadOnlySpan<int> values); }

Benchmark (boxed vs generic)

[MemoryDiagnoser]
public class BoxingBench
{
    private readonly int[] _data = Enumerable.Range(0, 1000).ToArray();

    [Benchmark]
    public int Boxed()
    {
        var sum = 0;
        IValueSink sink = new BlackHole();
        for (int i = 0; i < _data.Length; i++) sink.Add(_data[i]);
        return sum;
    }

    [Benchmark]
    public int Generic()
    {
        var sum = 0;
        IValueSink<int> sink = new BlackHoleInt();
        for (int i = 0; i < _data.Length; i++) sink.Add(_data[i]);
        return sum;
    }
}

Sample Result (Release, .NET 9, x64)

The “0 B” line is the goal you want in tight loops.

Real code #2 – Closures that capture too much

Lambdas can capture locals. The compiler then lifts them into a heap object.

Func<int, int> MakeAdder(int x)
{
    int hitCount = 0; // captured -> heap object created
    return y => { hitCount++; return x + y; };
}

If this runs per request, you allocate per request. In a hot path, prefer static lambdas and pass state explicitly:

int Add(int x, int y) => x + y;

var sum = data.Aggregate(0, static (acc, item) => Add(acc, item)); // no capture

Or use local functions that avoid capture:

int Sum(int[] items)
{
    int acc = 0;
    for (int i = 0; i < items.Length; i++) acc += items[i];
    return acc; // no heap allocations
}

Profiler tip: In dotMemory look for System.Runtime.CompilerServices.Closure and friends. In Visual Studio “Allocation” view, filter by new and find methods with a closure icon.

Real code #3 – stackalloc + Span<T> for small buffers

Parsing or formatting tiny chunks? Keep the buffer on the stack and avoid the heap.

public static int ParseHex(ReadOnlySpan<char> s)
{
    Span<byte> buf = stackalloc byte[8]; // good for up to 16 hex chars parsed to bytes
    int count = 0;

    for (int i = 0; i < s.Length; i += 2)
    {
        byte hi = HexNibble(s[i]);
        byte lo = HexNibble(s[i + 1]);
        buf[count++] = (byte)((hi << 4) | lo);
    }

    int value = 0;
    for (int i = 0; i < count; i++) value = (value << 8) | buf[i];
    return value;

    static byte HexNibble(char c)
        => (byte)(c <= '9' ? c - '0' : 10 + (c | 32) - 'a');
}

When stackalloc shines

• Buffers are small (tens to a few hundred bytes).
• Lifetime is strictly within the method.
• You don’t need to hand it off to async work.

If the buffer can grow or outlive the method, use ArrayPool<T> instead.

Real code #4 – struct vs class in practice

public readonly struct Vector2f
{
    public readonly float X;
    public readonly float Y;
    public Vector2f(float x, float y) => (X, Y) = (x, y);
    public Vector2f Add(in Vector2f other) => new(X + other.X, Y + other.Y);
}

public sealed class Vector2fRef
{
    public float X;
    public float Y;
    public Vector2fRef(float x, float y) => (X, Y) = (x, y);
    public Vector2fRef Add(Vector2fRef other) => new(X + other.X, Y + other.Y);
}

Benchmark: sum 1,000 vectors

[MemoryDiagnoser]
public class VectorBench
{
    private readonly Vector2f[] _a = Enumerable.Range(0, 1000).Select(i => new Vector2f(i, i)).ToArray();
    private readonly Vector2fRef[] _b = Enumerable.Range(0, 1000).Select(i => new Vector2fRef(i, i)).ToArray();

    [Benchmark]
    public Vector2f StructSum()
    {
        var s = new Vector2f(0, 0);
        for (int i = 0; i < _a.Length; i++) s = s.Add(_a[i]);
        return s;
    }

    [Benchmark]
    public Vector2fRef ClassSum()
    {
        var s = new Vector2fRef(0, 0);
        for (int i = 0; i < _b.Length; i++) s = s.Add(_b[i]);
        return s;
    }
}

Sample Result

Why? The struct array stores values inline; no extra objects for each element. The class array stores references that point to 1,000 separate heap objects.

Kill the most common heap churn

1. String concat in loops

• Replace with StringBuilder, or better: format into a stack or pooled buffer and write once.

1. new byte[XYZ] per request

• Use ArrayPool<byte>.Shared.Rent(...) and return with Return(...).

1. LINQ in inner loops

• Many operators allocate iterators and closures. Hand‑write the loop in hot spots.

1. Exceptions for control flow

• Throwing allocates; reserve it for exceptional cases.

1. Event handlers not removed

• Long‑lived publishers hold short‑lived subscribers; memory sticks around.

1. Timers and Task.Run that capture state

• Use static delegates and pass state to avoid closure objects.

Deep dive: arrays, LOH, and copy costs

• Arrays are always heap. Even new int[4] lives on the heap.
• Arrays of struct store elements inline (good locality), arrays of class store references (extra indirection).
• When arrays hit the LOH threshold (around 85 KB), they end up in LOH. These are collected with Gen 2 and can linger, so prefer pooling for big buffers.
• Copying big arrays is costly in both CPU and cache. Span<T> + MemoryMarshal lets you slice without copying (just be careful with lifetime).

public static ReadOnlySpan<byte> Header(ReadOnlySpan<byte> packet)
{
    // No copy: take first 32 bytes as a view
    return packet.Slice(0, 32);
}

Hands-on: measure before and after with BenchmarkDotNet

Add a benchmark project:

mkdir PerfLab && cd PerfLab
dotnet new console -n PerfLab
cd PerfLab
dotnet add package BenchmarkDotNet --version 0.14.0

Sample benchmark template:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]
public class ParseBench
{
    private readonly string[] _hex = new[] { "0A1B2C3D", "FFFFFFFF", "01234567" };

    [Benchmark]
    public int HeapParse()
    {
        var sum = 0;
        foreach (var s in _hex)
        {
            var bytes = Enumerable.Range(0, s.Length / 2)
                .Select(i => Convert.ToByte(s.Substring(2 * i, 2), 16))
                .ToArray(); // allocs
            for (int i = 0; i < bytes.Length; i++) sum += bytes[i];
        }
        return sum;
    }

    [Benchmark]
    public int StackParse()
    {
        var sum = 0;
        foreach (var s in _hex)
        {
            sum += ParseHex(s);
        }
        return sum;
    }

    // from earlier
    static int ParseHex(ReadOnlySpan<char> s) { /* ... */ return 0; }
}

public static class Program
{
    public static void Main() => BenchmarkRunner.Run<ParseBench>();
}

Sample Result

The speedup is nice, but the real win is no allocations.

Ref returns and ref struct types

Span<T>, ReadOnlySpan<T>, Utf8JsonReader, and friends are ref struct types:

• They must live on the stack (can’t be boxed or stored in fields).
• They help you work with memory without allocations.
• You can return by ref to avoid copies for large structs, but be strict with lifetime rules.

ref struct BufferWindow
{
    public Span<byte> Slice;
    public BufferWindow(Span<byte> slice) => Slice = slice;
}

Use these to pass views into existing data instead of creating new arrays or strings.

Patterns that look safe but allocate

• foreach on string.Split(...) allocates an array; prefer Span-based splitters (SearchValues<T>, IndexOfAny loops).
• ToList(), ToArray() in a chain – sneaky; do it once at the end, not in every step.
• Boxing via IComparable, IFormattable, non‑generic collections like ArrayList.
• Capturing this in async lambdas inside ASP.NET handlers.
• Logging with message templates that format large objects; use ILogger with structured fields (still watch boxing for value types).

Decision guide: struct or class?

Pick struct when:

• Size ≤ 16–32 bytes (rule of thumb) and copied often.
• Immutable; equality is by value.
• You need arrays of them for tight loops.

Pick class when:

• Identity matters; you share it across the graph.
• Size grows or fields mutate over time.
• You store it in hash sets/dicts with long lifetimes.

If in doubt: Start with class, benchmark, then switch to struct in hot paths that need it. Measure both CPU and Alloc/Op.

Checklist: win back memory today

• [ ] Add [MemoryDiagnoser] to your perf tests; aim for 0 B in inner loops.
• [ ] Hunt for boxing: switch to generics, in parameters, or custom formatters.
• [ ] Replace small new byte[] with stackalloc where safe.
• [ ] Replace big new byte[] with ArrayPool<T>. Always return to pool.
• [ ] Remove LINQ from inner loops that run millions of times.
• [ ] Make logging cheap; avoid building strings when log level is off.
• [ ] Kill event leaks; unsubscribe, or weak events for long‑lived publishers.
• [ ] Watch LOH: pool big arrays; stream instead of buffering the world.

FAQ: quick answers you can use

Conclusion: ship faster code by owning your allocations

You don’t need magic. You need eyes on Alloc/Op and a few sharp tools: avoid boxing, keep small buffers on the stack, pool the big ones, and trim closures from hot loops. Do this and you’ll cut GC time and latency right away.

Which allocation did you kill today, and what did it save you? Drop your numbers in the comments – I’ll add the best ones to a follow‑up.