SharpZipLib icon indicating copy to clipboard operation
SharpZipLib copied to clipboard

Perf - Add buffer pooling where relevant

Open thibault-reigner opened this issue 2 years ago • 0 comments

Current situation

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)
  • use ArrayPool all the time, this is choice taken by Microsoft in DeflateStream. 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 the Shared pool and returned when the stream is disposed (https://source.dot.net/#System.IO.Compression/System/IO/Compression/DeflateZLib/DeflateStream.cs,109)
  • any mix of the two previous solutions.

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

thibault-reigner avatar Apr 25 '23 06:04 thibault-reigner