Intro

Span<T> is a stack-only view over contiguous memory. It does not own data, it only points to existing memory (array, stackalloc buffer, or unmanaged memory). Use it when you need high-performance slicing/parsing with minimal allocations.

Span<T> gives bounds-checked access to a contiguous region with very low overhead:

• Slicing creates lightweight subviews without copying data.
• It can wrap array segments and stack-allocated buffers.
• Because it is a ref struct, it cannot escape to the managed heap.

Structure

graph LR
    A[array zero ten] --> B[array one twenty] --> C[array two thirty] --> D[array three forty]
    S[span start two length two] --> C
    S --> D

Example

Span<int> values = stackalloc int[] { 10, 20, 30, 40 };
Span<int> tail = values.Slice(2); // 30, 40

tail[0] = 300;
Console.WriteLine(values[2]); // 300

Pitfalls

• Returning a Span<T> that points to stack memory is invalid because the underlying buffer is gone after method return. Keep span lifetimes within the owning scope.
• Span<T> cannot be used across await boundaries because it is stack-only. Use Memory<T> for async flows.
• Converting every API to Span<T> can hurt readability when performance is not a bottleneck. Apply it to measured hot paths.

Tradeoffs

• Span<T> vs T[]: spans avoid copies for slicing, arrays are simpler when you need ownership and long-lived storage.
• Span<T> vs Memory<T>: spans are best for synchronous fast paths, Memory<T> is better when data must survive async boundaries.

Questions

Links