Span<T> ist ein mit C# 7.2 / .NET Core 2.1 (2018) eingeführter, hochoptimierter Strukturtyp, der einen zusammenhängenden Speicherbereich beliebiger Herkunft (Heap, Stack, unmanaged Memory) typsicher und ohne Allokation als Sequenz beschreibt. Er ist als ref-struct realisiert, was bedeutet, dass er den Stack nicht verlassen darf — eine Beschränkung, die starke Sicherheits- und Performance-Garantien ermöglicht.
Eingesetzt wird Span<T> in performance-kritischem Code: beim Parsen von Strings, Bytes oder JSON, in High-Performance-Netzwerk-Stacks (Kestrel, gRPC), in Serialisierern (System.Text.Json), in Datei- und Stream-Verarbeitung, in der numerischen Verarbeitung von Buffern und in Bibliotheken wie System.IO.Pipelines. Die verwandten Typen Memory<T>, ReadOnlySpan<T> und ReadOnlyMemory<T> ergänzen das Modell um asynchrone Szenarien und unveränderliche Sichten.
Der Einsatzzweck und das gelöste Problem liegen in der Vermeidung unnötiger Speicher-Allokationen und Kopien. Klassische .NET-Code-Pfade haben für Substring-Operationen oder Buffer-Manipulationen häufig neue Strings oder Arrays angelegt, was Garbage-Collector-Druck und Latenz erzeugt hat. Span<T> erlaubt es, Teilbereiche bestehender Buffer ohne Kopie als unabhängige Sequenz zu behandeln und Operationen wie split, trim, parse zero-allocation zu implementieren. Damit lassen sich Hochlast-Pfade um Größenordnungen schneller machen.
Historisch ist Span<T> Bestandteil eines mehrjährigen Performance-Programms im .NET-Team, in dem viele Standardbibliotheken (System.IO, System.Net.Sockets, System.Text.Json, regex) intern auf Span umgebaut wurden. Mit Native AOT, SIMD-Optimierungen und dem Pinning-Heap (POH) ab .NET 5 ist das Span-Modell zur Standardgrundlage moderner High-Performance-APIs in .NET geworden.
Eingeführt wurde Span<T> federführend von Krzysztof Cwalina, Stephen Toub und Jan Kotas. Stephen Toub hat in seiner heute legendären ‚Performance Improvements in .NET'-Reihe (jährliche Blogposts zur jeweils neuen .NET-Version) Span<T> dutzendfach als Hebel beschrieben, mit dem konkrete Microsoft-eigene Bibliotheken oft 2x bis 10x schneller wurden — diese Posts gelten in der .NET-Community als Standardquelle, um zu verstehen, warum eine vermeintlich konservative Plattform wie .NET in Benchmarks immer wieder mit Go, Rust und C++ gleichauf gelistet wird.