DEV Community: Alexey Popov

A single allocation is cheap. Millions of them can turn into latency spikes. This article explores how real .NET 10 and ASP.NET Core 10 APIs use stackalloc, Span, Memory, and object pools to reduce unnecessary allocations in high-throughput systems.

Alexey Popov — Wed, 16 Sep 2026 15:22:59 +0000

Alexey Popov

Sep 16

High-Performance .NET: Reducing Garbage Collector Overhead by Cutting Allocations

#dotnet #aspnetcore #performance #latencyspikes

10 min read

High-Performance .NET: Reducing Garbage Collector Overhead by Cutting Allocations

Alexey Popov — Wed, 16 Sep 2026 14:38:47 +0000

In the Understanding Memory in .NET article, we explored how memory management works in .NET and learned that objects allocated on the managed heap eventually have to be processed by the garbage collector. For most applications, garbage collection is barely noticeable. In high-throughput systems, however, millions of short-lived objects can trigger more frequent collections, increase latency, and reduce throughput [1].

Performance-sensitive .NET code therefore aims to avoid unnecessary allocations and reduce the amount of work left for the garbage collector.

The techniques discussed in this article follow three general principles:

keep small temporary buffers off the managed heap;
avoid creating objects unnecessarily;
reuse objects that have already been created.

The right approach depends on the problem: whether new storage is actually required, how long the data must remain valid, and whether an existing object can be reused.

Let us see how these principles are applied in .NET 10 and ASP.NET Core 10.

Keep small temporary buffers off the managed heap

A temporary buffer can be allocated as an ordinary array:

byte[] buffer = new byte[256];

An array is an object on the managed heap. Even if it is needed for only a single method call, the garbage collector will eventually have to process it. When a buffer is small and its size is known in advance, stackalloc can allocate it on the stack instead:

Span<byte> buffer = stackalloc byte[256];

This storage exists only until the method returns and does not create an object on the managed heap. Here, the result of stackalloc is assigned to a Span<byte>, so the buffer can be accessed through ordinary bounds-checked indexing without pointers or unsafe code [2].

A real-world example appears in the TryDecodeMime method of ContentDispositionHeaderValue, implemented in ContentDispositionHeaderValue.cs. A Content-Disposition HTTP header may contain a MIME-encoded file name:

attachment; filename="=?utf-8?B?0L7RgtGH0ZHRgi50eHQ=?="

To decode the file name, TryDecodeMime splits the MIME encoded-word on the ? character. The supported format produces five parts, whose boundaries are stored in a small stack-allocated buffer:

Span<Range> parts = stackalloc Range[6];
ReadOnlySpan<char> processedInputSpan = processedInput;

// "=, encodingName, encodingType, encodedData, ="
if (processedInputSpan.Split(parts, '?') != 5 || 
    processedInputSpan[parts[0]] is not "\"=" ||
    processedInputSpan[parts[4]] is not "=\"" ||
    !processedInputSpan[parts[2]].Equals("b", StringComparison.OrdinalIgnoreCase))
{
    return false;
}

ReadOnlySpan<char>.Split writes only the ranges of the resulting parts into parts, but the characters themselves remain in the original string. Unlike string.Split, this parsing step does not create an array and a separate string for every part.

There are several important restrictions to keep in mind [2]:

use stackalloc only for small buffers with a controlled size, because the stack is much smaller than the heap, and an allocation that is too large can cause a StackOverflowException;
avoid stackalloc inside loops because the allocated storage is released only when the method returns;
a Span<T> that refers to a local stack buffer cannot be returned from the method because the underlying storage will no longer exist.

If the buffer size depends on input or can become large, use a bounded threshold and obtain the remaining storage another way. We will return to this topic a little later.

Avoid creating objects unnecessarily

The most effective way to reduce allocations is to avoid creating a new object when the same work can be performed through a view over existing data.

Use `Span<T>` to represent existing data

In the previous example, Span<T> provided safe access to memory allocated with stackalloc. The type is not limited to stack memory, however. Span<T> represents a contiguous region of memory backed by a stack buffer, an array, or unmanaged memory. The span itself neither owns nor copies that data [3].

Consider a simple example:

int[] numbers = { 10, 20, 30, 40 };

Span<int> slice = numbers.AsSpan(1, 2);
slice[0] = 99;

Console.WriteLine(numbers[1]); // 99

slice represents two elements of the original array, starting at index 1. No new array is created, so a change made through the span is visible in numbers as well.

Now consider the GetExtension method in Path.cs. It has two overloads: one accepts a string, while the other accepts a ReadOnlySpan<char>:

public static string? GetExtension(string? path);
public static ReadOnlySpan<char> GetExtension(ReadOnlySpan<char> path);

The string overload is only a wrapper around the core implementation:

public static string? GetExtension(string? path)
{
    if (path == null)
        return null;

    return GetExtension(path.AsSpan()).ToString();
}

The actual search for the extension is implemented by the ReadOnlySpan<char> overload:

public static ReadOnlySpan<char> GetExtension(ReadOnlySpan<char> path)
{
    int length = path.Length;

    for (int i = length - 1; i >= 0; i--)
    {
        char ch = path[i];
        if (ch == '.')
        {
            if (i != length - 1)
                return path.Slice(i, length - i);
            else
                return ReadOnlySpan<char>.Empty;
        }
        if (PathInternal.IsDirectorySeparator(ch))
            break;
    }

    return ReadOnlySpan<char>.Empty;
}

This implementation returns a range within the original path rather than a new string. Calling path.AsSpan() in the string overload does not allocate either. A new object is created only by ToString(), when the result has to become an independent string.

Use `Memory<T>` when a view must be retained

Span<T> is declared as a ref struct. This allows it to safely represent stack memory, but it also requires the compiler to restrict its lifetime. Those restrictions apply even when a particular span is backed by an ordinary managed array: it cannot be stored in a field of a regular object or kept across an await boundary [3].

Some operations need to retain a view of memory and access it later. Memory<T> is designed for this purpose. The distinction is easy to see in the signatures of two overloads from Stream.cs [3]:

public virtual int Read(Span<byte> buffer);
public virtual ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken cancellationToken = default);

The synchronous Read completes before control returns to its caller, so it can accept a Span<byte>. ReadAsync, by contrast, may return an incomplete ValueTask<int> and continue writing later. It therefore needs a representation of the buffer that can be retained, which is why it accepts Memory<byte>.

Derived stream types can override these methods and operate directly on the supplied memory. We will examine the base implementation of ReadAsync(Memory<byte>) later.

An array can be passed to an asynchronous method as Memory<byte> without copying its contents:

byte[] buffer = new byte[4096];
Memory<byte> memory = buffer.AsMemory();

int bytesRead = await stream.ReadAsync(memory, cancellationToken);
Process(memory.Span[..bytesRead]);

AsMemory() does not create another buffer. The Memory<T> remains valid until the asynchronous operation completes, and after the await, its Span property provides access to the filled portion of the original array.

Memory<T> does not own the buffer. Until the asynchronous operation has completed, the caller must not reuse that memory or return it to a pool [4].

Both types therefore represent existing memory, but allow different lifetimes:

use Span<T> for immediate, synchronous access to data;
use Memory<T> when the view must be retained, for example until an asynchronous operation completes.

Reuse objects that have already been created

A view over existing data is not always enough. An operation may require a separate buffer or object. If that resource is needed repeatedly, it can be rented from a pool and returned after use instead of being created for every call.

Use `MemoryPool<T>` to reuse contiguous memory regions

When an operation simply needs a contiguous region of memory, it can rent one from MemoryPool<T>:

using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(minimumSize);
Memory<byte> memory = owner.Memory[..minimumSize];

await stream.ReadExactlyAsync(memory, cancellationToken);

The pool returns an IMemoryOwner<T>, which explicitly owns the rented memory. Its Memory<T> can be stored and passed to asynchronous operations while the owner remains alive. Calling Dispose() releases the rented memory back to the pool [3, 5].

This abstraction is useful when an algorithm does not care what kind of storage backs the returned memory. A custom pool implementation can abstract over different kinds of backing storage.

The System.IO.Pipelines library uses MemoryPool<T> to manage its internal buffers. A Pipe connects a producer of data to a consumer. The producer might read bytes from a network connection or stream and write them through a PipeWriter. The consumer retrieves those bytes through a PipeReader and parses them. The pipeline manages the buffers between them, so application code does not have to allocate a new array for every operation [6].

The producer asks the PipeWriter for memory and writes directly into it:

Memory<byte> memory = writer.GetMemory(minimumSize);
int bytesRead = await stream.ReadAsync(memory, cancellationToken);

writer.Advance(bytesRead);
FlushResult result = await writer.FlushAsync(cancellationToken);

The consumer receives the written data as a ReadOnlySequence<byte>, which may span multiple memory regions:

ReadResult result = await reader.ReadAsync(cancellationToken);
ReadOnlySequence<byte> buffer = result.Buffer;

// Parse the available data and determine the consumed and examined positions.

reader.AdvanceTo(consumed, examined);

The consumed position tells the pipeline which memory can be reused, while examined indicates how far the consumer inspected the data. After calling AdvanceTo, code must not retain references to the released portion of the buffer [6].

FlushAsync helps coordinate the rate of production with the rate of consumption. If too much unprocessed data accumulates, the producer pauses until the consumer releases part of the buffer. This helps contain buffer growth when the consumer processes data more slowly than the producer generates it [6].

Use `ArrayPool<T>` to reuse arrays

MemoryPool<T> is not suitable for every situation. Some APIs specifically require a T[], so an ordinary array is needed to call them. ArrayPool<T> can provide one without allocating a new array for every operation [7].

The base implementation of Stream.ReadAsync(Memory<byte>), which we mentioned earlier, demonstrates this approach. If the memory is not backed by an accessible array, the fallback path rents a temporary byte[] from ArrayPool<byte>:

byte[] sharedBuffer = ArrayPool<byte>.Shared.Rent(buffer.Length);
return FinishReadAsync(ReadAsync(sharedBuffer, 0, buffer.Length, cancellationToken), sharedBuffer, buffer);

static async ValueTask<int> FinishReadAsync(Task<int> readTask, byte[] localBuffer, Memory<byte> localDestination)
{
    try
    {
        int result = await readTask.ConfigureAwait(false);
        new ReadOnlySpan<byte>(localBuffer, 0, result).CopyTo(localDestination.Span);
        return result;
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(localBuffer);
    }
}

Here, Rent() replaces a temporary new byte[...] allocation, while the finally block ensures that Return() gives the array back to the pool even if the read fails.

Unlike MemoryPool<T>, this API does not return a separate owner object. Rent() returns the array itself, and its length may be greater than requested. The caller must track the amount of valid data and return the same array manually with Return() [7].

The array must not be accessed after it has been returned because another part of the program may rent it next. The pool also does not clear arrays automatically. For sensitive data, pass clearArray: true to Return() or clear the region that was used before returning the array [7].

Use `ObjectPool<T>` to reuse ready-to-use objects

MemoryPool<T> and ArrayPool<T> reuse regions of memory. Sometimes, however, the resource to reuse is an object itself, together with its configuration and internal state. ObjectPool<T> is intended for this scenario [8].

A real example appears in NewtonsoftJsonInputFormatter.cs in ASP.NET Core 10. This component deserializes HTTP request bodies using Newtonsoft.Json's JsonSerializer. Instead of creating and configuring a new serializer for every request, the formatter keeps a pool of ready-to-use instances:

private ObjectPool<JsonSerializer>? _jsonSerializerPool;

protected virtual JsonSerializer CreateJsonSerializer()
{
    if (_jsonSerializerPool == null)
    {
        _jsonSerializerPool = _objectPoolProvider.Create(new JsonSerializerObjectPolicy(SerializerSettings));
    }

    return _jsonSerializerPool.Get();
}

Before deserialization, the formatter obtains a serializer from the pool and attaches an error handler for the current request. In the finally block, it removes that handler and returns the object to the pool:

var jsonSerializer = CreateJsonSerializer(context);
jsonSerializer.Error += ErrorHandler;

try
{
    model = jsonSerializer.Deserialize(jsonReader, type);
}
finally
{
    jsonSerializer.Error -= ErrorHandler;
    ReleaseJsonSerializer(jsonSerializer);
}

ReleaseJsonSerializer returns the used serializer to the pool:

protected virtual void ReleaseJsonSerializer(JsonSerializer serializer)
    => _jsonSerializerPool!.Return(serializer);

Removing the handler before returning the serializer is essential: the next request may receive the same instance and must not inherit state from the previous operation. Unlike the memory pools, this pool reuses a configured JsonSerializer object with its own behavior and state, not merely an array of elements.

Pooling is worthwhile only for objects that are expensive to create or initialize and are used frequently enough. ObjectPool<T> limits how many objects it retains, not how many it can create. If no instance is available, Get() creates a new one. Once an object has been returned, it must no longer be used because another caller may acquire it [8].

Conclusion

Despite their differences, all the techniques discussed here follow three general principles: keep small temporary buffers off the managed heap, avoid creating objects unnecessarily, and reuse objects that have already been created.

Choosing the right tool depends on the lifetime of the data and how it will be used. A small local buffer can live on the stack, existing data can be exposed through a non-copying view, and a resource that must be created can be returned to a pool for reuse.

The goal is not to eliminate every allocation. The final string, object, or array is often genuinely necessary. The important distinction is between data the application actually needs and temporary objects introduced only by the way that data is processed.

Begin this kind of optimization with measurements. More complex memory management is justified only when reducing garbage-collection work produces a meaningful benefit and the ownership rules remain clear.

References

Understanding Memory in .NET

Alexey Popov — Thu, 03 Sep 2026 15:08:16 +0000

Introduction

With the rise of large language models (LLMs), the distinction between writing code and programming has become more apparent than ever.

To an LLM, source code is merely text. To a computer, it is a sequence of instructions. A developer’s task is to understand what actually happens when those instructions are executed.

This is why studying a programming language often begins not with syntax, but with the program’s execution model. One of the most important parts of that model is memory: how data is represented, how it is copied, how long it remains alive, and how different pieces of data interact while a program is running.

In this article, we will explore two primary memory regions used by .NET applications, why they serve different purposes, and how this design influences both the behavior and performance of .NET applications.

Memory Regions

When a .NET application starts, the operating system creates a process and its first execution thread (primary thread). The Common Language Runtime (CLR) is then initialized and takes responsibility for executing the application, including managing the Managed Heap and the Garbage Collector [1].

During execution, additional threads may be created by the application or used by the runtime. Each thread has its own Stack and CPU register state [1].

As a result, a running .NET application relies on two primary memory regions:

Stack - private to each thread and used for method execution and local state [1]
Managed Heap - shared by threads in the process and managed by the CLR's Garbage Collector [2]

But why does the platform need two different memory regions?

Because different kinds of data have different requirements regarding access speed, lifetime, and storage.

Data Representation

In .NET, there are two fundamental ways of representing data: Value Types and Reference Types [3].

Value Types

Value Types are used when only the value itself matters.

Consider a simple example:

int x = 10;
int y = x;
y = 20;

After the assignment, the program contains two independent copies of the value. Changing one variable has no effect on the other because each variable stores its own value [3]:

Figure 1. Assigning a Value Type creates an independent copy of the value

From the CLR’s perspective, such data does not need a distinct identity because only the value matters. Its exact storage location is therefore determined entirely by the context in which it is used.

This is why small, independent pieces of data (numbers, coordinates, dates, dimensions, or colors) are commonly represented as Value Types in .NET.

For example, an application may store the coordinates of millions of points on a map or the vertices of a three-dimensional model. Each point is merely a set of numbers. Copying such values is a natural process and does not require the creation of separate objects with their own identities.

Reference Types

Reference Types, by contrast, are used when not only the information matters, but also the identity of the entity to which that information belongs.

For example:

var user1 = new User();
var user2 = user1;
user2.Age = 30;

After the user1 and user2 assignments, both variables refer to the same object [3]:

Figure 2. Assigning a Reference Type copies the reference, not the object

Such an object may be passed between methods, returned from them, stored in collections, and remain alive far longer than any individual method call. Its lifetime must therefore not depend on a particular stack frame. Instances of Reference Types are allocated on the Managed Heap [2].

Reference Types are therefore well suited to modeling entities shared by multiple parts of a program. An object of User class, for example, may be displayed in the user interface, stored in a collection, passed to a service, and used by an authentication system. All of these components must work with the same object instance rather than with independent copies.

The same principle underlies most dynamic data structures. A linked list, for instance, consists of nodes, each of which stores a reference to the next node:

class Node
{
    public int Value;
    public Node? Next;
}

Reference semantics make this representation natural: nodes can be connected and rearranged by changing references without copying the nodes themselves.

Choosing between Value Types and Reference Types is therefore not primarily a matter of performance or coding style - it is a matter of modeling data correctly. As a general modeling principle, Value Types are well suited to independent values, while Reference Types are well suited to entities whose identity and shared state matter.

Boxing and Unboxing

.NET is built around an unified type system whose root is System.Object [3].

As a result, a value of any type can be treated as an object when necessary [4].

For example:

List<object> values = new();

values.Add("Alice");
values.Add(42);
values.Add(DateTime.Today);

string is already a Reference Type, but 42 and DateTime.Today are Value Types. So how can they all be stored in the same collection?

Boxing

Boxing is the implicit conversion of a Value Type to object or to an interface implemented by that type [4]:

int i = 123;
object o = i;

i = 456;

During boxing, the CLR [4]:

Allocates memory on the Managed Heap.
Creates a new object.
Copies the value into that object.

Figure 3. Boxing creates a new object on the Managed Heap containing a copy of the value

Boxing does not move a value from the Stack to the Managed Heap. Instead, the CLR allocates a new object on the heap and copies the value into it [4]. The original value remains independent of the boxed copy.

Every boxing operation therefore creates an additional heap object. Although allocating memory on the Managed Heap is generally fast, repeated boxing creates additional allocations and can increase the amount of work the Garbage Collector must eventually perform [4].

Unboxing

After boxing, the value is represented as an object. To use it again as an int, DateTime, or any other Value Type, it must first be unboxed [4]:

object val = 42;
int num = (int)val;
num = 99;

During unboxing, the CLR [4]:

Verifies that the object contains a value of the expected type.
Copies that value into a new variable.

Figure 4. Unboxing copies the value from the boxed object into a new Value Type variable

The boxed object itself remains on the Managed Heap until it eventually becomes unreachable, and its memory can be reclaimed by the Garbage Collector.

Garbage Collector

As long as an object exists on the Managed Heap, the CLR must eventually determine when its memory can be reclaimed. This responsibility belongs to the Garbage Collector, which serves as .NET's automatic memory manager [2].

When a garbage collection is triggered, the Garbage Collector examines the object graph starting from a set of Garbage Collector Roots, determining which objects are still reachable. Objects that cannot be reached from these roots are considered garbage and their memory can be reclaimed [2].

Allocating objects on the managed heap is generally very fast because, while space is available, allocation primarily involves advancing a pointer [2]. However, increasing the number and rate of heap allocations increases the amount of work the Garbage Collector may need to perform.

Moreover, if an object remains reachable - for example, through a static field or a collection - the GC considers it alive and will not reclaim its memory. Keeping references to objects that are no longer logically needed can therefore cause memory leaks even in managed applications [2].

Conclusion

Looking at the complete picture, it becomes clear that these mechanisms are not isolated features but parts of a single execution model.

Understanding this model allows us to see .NET not as a collection of unrelated features, but as a coherent system whose components naturally build upon one another. This is why understanding the memory model forms the foundation for understanding many other parts of the modern .NET platform, including Span<T>, stackalloc, async/await, yield, and many others.

DEV Community: Alexey Popov

A single allocation is cheap. Millions of them can turn into latency spikes. This article explores how real .NET 10 and ASP.NET Core 10 APIs use stackalloc, Span, Memory, and object pools to reduce unnecessary allocations in high-throughput systems.

High-Performance .NET: Reducing Garbage Collector Overhead by Cutting Allocations

High-Performance .NET: Reducing Garbage Collector Overhead by Cutting Allocations

Keep small temporary buffers off the managed heap

Avoid creating objects unnecessarily

Use Span<T> to represent existing data

Use Memory<T> when a view must be retained

Reuse objects that have already been created

Use MemoryPool<T> to reuse contiguous memory regions

Use ArrayPool<T> to reuse arrays

Use ObjectPool<T> to reuse ready-to-use objects

Conclusion

References

Understanding Memory in .NET

Introduction

Memory Regions

Data Representation

Value Types

Reference Types

Boxing and Unboxing

Boxing

Unboxing

Garbage Collector

Conclusion

References

Use `Span<T>` to represent existing data

Use `Memory<T>` when a view must be retained

Use `MemoryPool<T>` to reuse contiguous memory regions

Use `ArrayPool<T>` to reuse arrays

Use `ObjectPool<T>` to reuse ready-to-use objects