Some pieces of code such as InflaterInputStream, through InflaterInputStream, allocate buffers upfront in their constructors, with no way to control this behavior (e.g : passing the buffer to use).
In code making intensive use of such classes (e.g : app sending huge amounts of compressed data in my case), this can result in this being unsustainable in term of resulting GC load.
Describe the solution you'd like
I would like to suggest some alternatives :
add constructors overload admitting the buffer to use (so client can handle the reuse logic)
Current situation
Some pieces of code such as
InflaterInputStream, throughInflaterInputStream, allocate buffers upfront in their constructors, with no way to control this behavior (e.g : passing the buffer to use). In code making intensive use of such classes (e.g : app sending huge amounts of compressed data in my case), this can result in this being unsustainable in term of resulting GC load.Describe the solution you'd like
I would like to suggest some alternatives :
ArrayPoolall the time, this is choice taken by Microsoft inDeflateStream. While it allocates a new buffer on Net Fx (https://referencesource.microsoft.com/#System/sys/System/IO/compression/DeflateStream.cs,63), on Net Core it is always retrieved from theSharedpool and returned when the stream is disposed (https://source.dot.net/#System.IO.Compression/System/IO/Compression/DeflateZLib/DeflateStream.cs,109)Describe alternatives you've considered
Due to current design of most classes there is sadly no alternative as there is no control over the buffers allocations in constructors.
Tags
Performance