You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
ArrayPool
all 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 theShared
pool 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
The text was updated successfully, but these errors were encountered: