ArrayPoolWrapper is a lightweight wrapper around .NET
ArrayPool<T>, designed to solve the boilerplate, missed cleanup on exception paths, and poor maintainability that often come with manualRent/Returnusage. It simplifies pooled array handling throughIDisposable, capacity validation, andSpanviews. Keywords: ArrayPool, C#, performance optimization.
Technical specifications are easy to scan
| Parameter | Description |
|---|---|
| Language | C# / .NET |
| Core protocols/interfaces | IDisposable, `Span |
| ` | |
| GitHub stars | Not provided in the original article |
| Core dependency | `System.Buffers.ArrayPool |
| ` | |
| Best-fit scenarios | High-frequency array allocation, low GC pressure, short-lived buffers |
ArrayPool reduces frequent allocations and GC overhead
`ArrayPool
` is the foundational array reuse infrastructure in .NET. For short-lived, frequently created `T[]` instances, it avoids repeated managed memory allocations, which reduces GC pressure and improves throughput. However, the native API is fairly low-level. While the calls themselves are simple, real-world business logic often fills up with boilerplate because of exception handling and return-to-pool requirements. “`csharp using System.Buffers; var buffer = ArrayPool .Shared.Rent(4); // Rent an array from the shared pool // Execute business logic here ArrayPool .Shared.Return(buffer); // Return it after use “` This example shows the most basic rent-and-return workflow. ## Native usage increases maintenance cost on exception paths If the business logic in the middle throws an exception, the array may never be returned. To guarantee cleanup, developers usually have to write `try/finally` explicitly, which introduces repeated templates and deeper indentation. “`csharp using System.Buffers; int[] buffer = null!; try { buffer = ArrayPool .Shared.Rent(4); // Rent an array // Execute business logic here } finally { if (buffer != null) { ArrayPool .Shared.Return(buffer); // Ensure it is returned even on exceptions } } “` The main purpose of this code is to ensure the array is safely returned to the pool on every execution path. ### Too much boilerplate directly hurts readability In performance-sensitive modules, array pooling often appears inside loops, parsers, serializers, or middleware pipelines. Once every usage site copies the same `try/finally` pattern, code review cost goes up and misuse becomes more likely. So the most practical optimization is not to replace `ArrayPool `, but to build a safer, thinner wrapper on top of it that better matches everyday coding habits. ## ArrayPoolWrapper uses IDisposable to provide concise cleanup semantics The goal of this wrapper is straightforward: move manual return logic into `Dispose`, so callers can use `using` and get an RAII-like experience. “`csharp using System; using System.Buffers; public struct ArrayPoolWrapper : IDisposable { private int _index; private bool _disposed; private readonly int _capacity; private readonly T[] _pool; public ArrayPoolWrapper(int capacity) { if (capacity .Shared.Rent(capacity); // Rent an array from the shared pool } public void Add(T item) { ThrowIfDisposed(); // Prevent use after disposal _index++; if (_index >= _capacity) { _index–; throw new InvalidOperationException(“The array pool has reached its capacity limit”); // Protect the capacity boundary } _pool[_index] = item; // Write the element } public void Dispose() { ThrowIfDisposed(); _disposed = true; ArrayPool .Shared.Return(_pool); // Return the array to the underlying shared pool } private readonly void ThrowIfDisposed() { if (_disposed) { throw new ObjectDisposedException(nameof(ArrayPoolWrapper )); } } } “` This code encapsulates array rental, writes, capacity control, and cleanup responsibility inside a single struct. ### The calling pattern shrinks to a single line After introducing the wrapper, business code no longer touches `Return` directly. That means `using` semantics provide exception safety by default, and the caller only needs to focus on the business logic. “`csharp using var pool = new ArrayPoolWrapper (5); // Automatically return the array when the scope ends “` This line provides safe pooled-array lifetime management with minimal cognitive overhead. ## Extended APIs make the wrapper more practical in real code Simply hiding `Return` is not enough. Exposing `Count`, `Values`, and the ability to remove the last element makes the wrapper feel more like a lightweight, business-facing container. “`csharp public struct ArrayPoolWrapper : IDisposable { public readonly int Count => _index + 1; // Number of active elements public readonly Span Values => _pool.AsSpan()[..Count]; // Expose the active data slice public void RemoveLastOne() { ThrowIfDisposed(); if (Count ` through `Values`, the caller can operate only on the valid range instead of dealing with the entire rented array. This avoids confusing out-of-range semantics and better fits high-performance data processing scenarios. “`csharp using var pool = new ArrayPoolWrapper (8); for (var i = 0; i ? `List ` is more general-purpose, but it can still trigger resizing and allocations underneath. If you are working in a high-frequency, short-lived object scenario, `ArrayPool` has a better chance of reducing GC pressure, and this wrapper fills in the usability gap. ### 2. What is the biggest benefit of this wrapper? The biggest benefit is that it collapses manual `Rent/Return` management into a `using/Dispose` pattern. That significantly reduces missed returns on exception paths, repeated template code, and nesting depth. ### 3. What should I watch out for when using a struct? You need to avoid unintentionally copying the struct instance, because that can lead to inconsistent state. In practice, keep it in a local scope whenever possible and avoid passing it by value across multiple methods. ## AI Readability Summary This article examines the common pain points of using .NET `ArrayPool ` directly and introduces a lightweight `ArrayPoolWrapper` as a refactored solution. By combining `IDisposable`, capacity boundary checks, and `Span` exposure, the wrapper reduces boilerplate, lowers the risk of missing `Return` on exception paths, and improves the readability and maintainability of pooled-array code.