Mind Archipelago

C# ArrayPool: Memory-Efficient Array Management

August 27, 2025

In performance-critical C# applications, memory allocation can become a significant bottleneck. One often-overlooked tool for optimizing memory usage is ArrayPool<T>, introduced in .NET Core 1.0 and available in .NET Standard 1.1+. This powerful utility can dramatically reduce garbage collection pressure and improve application performance when used correctly.

The Problem ArrayPool Solves

Every time you create an array in C#, the runtime allocates memory on the managed heap. For small, short-lived arrays, this isn’t problematic. However, when your application frequently creates temporary arrays—especially large ones—you encounter several issues:

  1. Garbage Collection Pressure: Each allocated array eventually becomes garbage, triggering GC cycles that can pause your application
  2. Memory Fragmentation: Frequent allocation and deallocation can fragment the heap, leading to inefficient memory usage
  3. Performance Overhead: Memory allocation isn’t free—it takes CPU cycles that could be spent on your application logic

Consider this common scenario:

public byte[] ProcessData(Stream input)
{
    // This creates a new 4KB array every time
    byte[] buffer = new byte[4096];
    
    // Process the data...
    input.Read(buffer, 0, buffer.Length);
    
    // Array becomes eligible for garbage collection when method returns
    return ProcessBuffer(buffer);
}

If this method is called thousands of times per second, you’re creating and discarding thousands of 4KB arrays, putting significant pressure on the garbage collector.

How ArrayPool Works

ArrayPool<T> maintains a pool of reusable arrays, allowing you to “rent” an array when needed and “return” it when finished. This eliminates the need for repeated allocations:

using System.Buffers;

public byte[] ProcessData(Stream input)
{
    // Get a shared pool instance
    var pool = ArrayPool<byte>.Shared;
    
    // Rent an array (at least 4096 elements)
    byte[] buffer = pool.Rent(4096);
    
    try
    {
        // Use the array normally
        input.Read(buffer, 0, 4096);
        return ProcessBuffer(buffer);
    }
    finally
    {
        // Always return the array to the pool
        pool.Return(buffer);
    }
}

Key Usage Patterns

Basic Rent and Return

The fundamental pattern involves three steps:

var pool = ArrayPool<T>.Shared;
T[] array = pool.Rent(minimumSize);
try
{
    // Use the array
}
finally
{
    pool.Return(array);
}

Working with Larger Arrays

ArrayPool may return arrays larger than requested for efficiency. Always use the size you actually need:

int requiredSize = 1000;
char[] buffer = ArrayPool<char>.Shared.Rent(requiredSize);

try
{
    // Only use the first 'requiredSize' elements
    for (int i = 0; i < requiredSize; i++)
    {
        buffer[i] = GetNextChar();
    }
}
finally
{
    ArrayPool<char>.Shared.Return(buffer);
}

Custom Pool Configuration

For specific needs, create a custom pool with different parameters:

// Create a pool with specific max array length and max arrays per bucket
var customPool = ArrayPool<byte>.Create(
    maxArrayLength: 1024 * 1024,  // 1MB max
    maxArraysPerBucket: 10        // Keep up to 10 arrays per size
);

Common Pitfalls and Mistakes

1. Forgetting to Return Arrays

Wrong:

public void ProcessData()
{
    var buffer = ArrayPool<byte>.Shared.Rent(1024);
    // Process data...
    // Oops! Forgot to return the array
}

Right:

public void ProcessData()
{
    var buffer = ArrayPool<byte>.Shared.Rent(1024);
    try
    {
        // Process data...
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer);
    }
}

2. Using Arrays After Returning Them

Wrong:

var buffer = ArrayPool<int>.Shared.Rent(100);
ArrayPool<int>.Shared.Return(buffer);

// This is dangerous! The array might be reused by another thread
buffer[0] = 42; // Potential race condition or corrupted data

3. Not Clearing Sensitive Data

By default, Return() doesn’t clear the array contents. For security-sensitive data:

var sensitiveBuffer = ArrayPool<char>.Shared.Rent(256);
try
{
    // Work with sensitive data...
}
finally
{
    // Clear the array before returning
    ArrayPool<char>.Shared.Return(sensitiveBuffer, clearArray: true);
}

4. Assuming Exact Array Sizes

Wrong:

var buffer = ArrayPool<int>.Shared.Rent(100);
// Assuming buffer.Length == 100
for (int i = 0; i < buffer.Length; i++) // Might process more than intended!
{
    ProcessElement(buffer[i]);
}

Right:

int neededSize = 100;
var buffer = ArrayPool<int>.Shared.Rent(neededSize);
for (int i = 0; i < neededSize; i++) // Use the size you actually need
{
    ProcessElement(buffer[i]);
}

5. Thread Safety Misunderstandings

While ArrayPool itself is thread-safe, the arrays it provides are not. Don’t share rented arrays between threads without proper synchronization.

When to Use ArrayPool

ArrayPool provides the most benefit in these scenarios:

✅ High-Frequency Temporary Arrays

✅ Large Arrays (>85KB)

✅ Performance-Critical Code Paths

// Good use case: High-frequency data processing
public async Task ProcessStreamAsync(Stream stream)
{
    var buffer = ArrayPool<byte>.Shared.Rent(8192);
    try
    {
        int bytesRead;
        while ((bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length)) > 0)
        {
            ProcessChunk(buffer, bytesRead);
        }
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer);
    }
}

When NOT to Use ArrayPool

❌ Long-Lived Arrays

If you need an array for the lifetime of an object, regular allocation is simpler and more appropriate.

❌ Small, Infrequent Arrays

The overhead of renting and returning isn’t worth it for small arrays used occasionally.

❌ Complex Ownership Scenarios

When array ownership is unclear or passes through many method calls, stick to regular arrays to avoid bugs.

❌ When Simplicity Matters More Than Performance

In non-performance-critical code, the added complexity might not be justified.

Conclusion

ArrayPool is a powerful tool for optimizing memory allocation in C# applications, but it requires careful consideration of when and how to use it. The key benefits—reduced GC pressure and improved performance—come at the cost of additional complexity and potential pitfalls.

Start by identifying hot paths in your application where temporary arrays are frequently allocated. Profile your application to measure the actual impact before and after implementing ArrayPool. Remember: premature optimization can hurt maintainability, so use ArrayPool when you have a clear performance need and the discipline to handle arrays correctly.

When used appropriately, ArrayPool can be the difference between an application that struggles under load and one that scales effortlessly.