ArrayPool<T>/MemoryPool<T> Best Practice

[GF-Huang]

When should they be used? Are there any guidelines?

And the docs said:

Using the ArrayPool class to rent and return buffers (using the Rent and Return methods) can improve performance in situations where arrays are created and destroyed frequently, resulting in significant memory pressure on the garbage collector.

It's not very clear, how frequent is frequent?

Is it premature optimization to use them instead of temporary arrays which created in the all method bodies?
Even refactor all short life object like the follow, is this bad?

class ShortLife : IDisposable {
    private byte[] _buffer;
    
    public ShortLife(...) {
        _buffer = ArrayPool<byte>.Shared.Rent(xxx);
    }
    public void Dispose() {
        ArrayPool<byte>.Shared.Return(_buffer);
    }
}

// then use
using var shortLife = new ShortLife(...);

[davidfowl]

The shared array pool is optimized for synchronous rent and return. I think that's where the short lived advice comes from.

[Clockwork-Muse]

The other thing that should be mentioned here is that if your array is also small (in bytes used - size of type * number of elements), in addition to being short-lived, it may behoove you to look at using stackalloced arrays.

[GF-Huang]

In the async method body, stackalloc seems cumbersome to use and requires a static local function.

[Clockwork-Muse]

And that's just another part of the determination. Although note that if you're in an async method, they may not "live" long enough - since in many cases you use the array as a buffer to an async call, you'd run into problems at that point.

[Akeit0]

I think we need guidelines.

I was optimizing Linq's TakeLast, but I have a different opinion from the reviewer regarding ArrayPool and yield. I would like official guidelines (at least for implementations within the BCL).

Me:
#118490 (comment)

The reason I return the array just before yielding is that not all yielding are done synchronously, and it is possible to hold an array rent from ArrayPool. In this case, it is customary not to use rent arrays.

Reviewer:
#118490 (comment)

Pooled buffers can certainly cross yield boundaries, it's just that you can no longer use stack allocated buffers.

[ichensky]

The use of ArrayPool.Rent and Return can be used, for example, within a loop where an array of varying size needs to be created multiple times. The ArrayPool attempts to re-use memory allocated for prior arrays.

for (int i =0; ... ){
    var buffer = ArrayPool<int>.Shared.Rent(N);
    ...
    ArrayPool.Return(buffer, clearArray: true);
}

However, in many cases, when N is constant (or when the exact value doesn't strictly matter), such code can be optimized by moving the buffer to an outer loop or function and just re-using it.

int[] buffer = new int[N];
for (int i =0; ... ){
    ...
}

[Clockwork-Muse]

Generally, you'd still rent/return even in the outer context.
Additionally, you're (almost) always supposed to use try { ... } finally { ... } to ensure that arrays are returned in the event of exceptions.

[gfoidl]

Additionally, you're (almost) always supposed to use try { ... } finally { ... } to ensure that arrays are returned in the event of exceptions.

No.
That can yield in use-after-retrun bug which are hard to diagnose. Now there's even an official best practice against using try-finally.

In the event of exceptions just let the GC collect the (rented) array. The array pool can handle such cases w/o problems.

[Clockwork-Muse]

.... and here I was approaching it from the perspective of it being the only return in the method.