Consider using ArrayPool<byte> as underlying storage mechanism

[benmwatson]

Pros? Cons?

Would it simplify implementation?

[sgorozco]

Hi Ben!
I really like your current implementation A LOT. It is very readable, tailor-made for the use-case and very easy to reason about; with nice event hooks to observe the operations, and very useful debugging utilities.

With ArrayPool being an abstract class, things are a bit blurrier. The Shared implementation looks complex, with multi-core optimizations that might improve performance, but then, you would be relying on a singleton class that is heavily used internally by the runtime libraries (at least in the .Net Standard 2.0 libraries) and that might dwarf the optimizations. The non-shared implementation looks much simpler but is restricted to work internally with buffers that are sized in powers-of-two and last time I checked, protects concurrent access via a SpinLock; It may offer better performance, but personally I like more being able to directly inspect the code as in your current implementation.

Currently I am using the library to implement extremely efficient channel multiplexing. I am concurrently serializing hundreds of large DTOs to Recyclable streams and the data slicing to enable the multiplexing is completely handled by your library, with zero-copy, zero-allocation. According to the profiler, now the "bottleneck" is curiously, on the Math.DivRem() operations that are done to locate the buffer to place a byte! I am really thankful.

I'm curious about your own thoughts? What are the reasons why you consider such a change?

[benmwatson]

It's been asked a couple of times, so I created this as a place for discussion.

[grbell-ms]

Adding to what @sgorozco said:

• ArrayPool<byte>.Shared only caches up to 32 arrays of the same size (not counting thread-locals). It would be extremely easy to exhaust/flood the shared array pool if RMS started using it.

• ArrayPool<byte>.Create() returns a ConfigurableArrayPool<byte>, which can return buffers twice as large as desired, making it very easy to waste memory.

RMS would need to use its own array pool implementation, which wouldn't simplify anything. However, it may be worth it to open up an extension point to let users control allocation. If we used ArrayPool<byte> as the interface, RMS should throw if either of the default implementations are used, and document how the custom pool should behave.