Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
compress/lzw: reduce garbage in encoder #26535
While we can't easily change the API in go1 to support reuse, we can greatly reduce garbage by pooling the
(Note that these are on top of my existing CL https://go-review.googlesource.com/c/go/+/123478 that improves time/op significantly)
I don't see much use of pools in the standard library, is this not generally a good approach? Even if it is, is the memory overhead worth it for the 4% performance increase?
Pools have subtle properties that affect their performance (see #23199 and #22950). While #23199 isn't an issue here since the object is fixed size, #22950 can have adverse affect in all usages of pools in certain workloads.
That being said, why do you say:
Is that because the API returns
A pool seems like a poor fit for this use-case, since the
Thanks for the insight, a
There's also the question of
One option would be for
Maybe 64k garbage is okay for an image encoder, in which case the