Closed greatroar closed 3 years ago
I was thinking about how we could solve the underlying issue: a sync.Pool
of []byte
does not perform well. The use of pooling the writeWork
is a good idea, although this particular implementation is a little clunky (to be fair, I also could not find a better way to do it.)
It occurred to me that we’re storing a very limited amount of buffers, and they’re all a consistent size. Knowing this, we can actually save even more allocs and time by just implementing a static pool ourselves. This better drop-in-replacement similar to the sync.Pool
means I was able to fix not just this WriteTo
implementation but the ReadFrom
implementation as well, which looked to be even more chunky if we wanted to store more than just the []byte
.
Closing in favor of #417.
This solves the common problem of []byte in sync.Pool causing many tiny allocations (and GC pressure), by instead pooling the writeWork structures. Benchmark results on Linux/amd64: