Difference between MemoryPool<T> and ArrayPool<T>

Question

What is the difference between MemoryPool and ArrayPool as far as i can tell, they both do the same thing (rent out buffers to reduce garbage collection pressure).

Is there a pool that should be be preferred in read calls to use NetworkStream or WebSocket?

Answer 1

The ArrayPool<T> class rents out Arrays. In otherwords the Rent method returns a T[]. The Shared property returns a default implementation of an ArrayPool<T>, TlsOverPerCoreLockedStacksArrayPool which caches the backing arrays in a combination of a ThreadStatic array of buckets and local per-core "stacks". It is optimized for the char and byte cases. The ConfigurableArrayPool returned from the Create method stores the underlying arrays in an array of Buckets (each with its own array of arrays). Additionally you may write your own implementation.

On the other hand, MemoryPool<T> is a bit more generic in that it deals ultimately with Memory<T> objects. The Rent method hands out IMemoryOwner<T> implementations, which are responsible for, well, owning a Memory<T>. Memory Owners can be backed by various sources, arrays being one of them. The MemoryPool<T>.Shared singleton is actually an ArrayMemoryPool<T> which is backed by, you guessed it, ArrayPool<T>.Shared. But memory pools may be backed by different sources, for example by unmanaged memory/memory pointed to by a SafeHandle.

Which one to use really depends on your requirements:

• If the API you are using requires a T[] or you simply want a no-allocation array, then ArrayPool<T> is what you want to use.

• If you are working with Memory<T> instances, then you want to use a MemoryPool<T>

If you are using an API that can take either, there's not necessarily a benefit to using one pool over the other. The API itself may work better with raw T[] than it does with Memory<T> (or vice versa), but the API should only care about the memory itself and has no knowledge of the pool from which it came.