Open benmwatson opened 9 months ago
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
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?
It's been asked a couple of times, so I created this as a place for discussion.
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.
DOTNET_SYSTEM_BUFFERS_SHAREDARRAYPOOL_MAXARRAYSPERPARTITION can be used to set the number of arrays cached.
I think there should be a way to configure RMS to use the ArrayPool<byte>.Shared
also.
Pros? Cons?
Would it simplify implementation?