Just FYI, there is currently the following activity regarding sync.Pool
optimizations that may land to go1.11:
- Increasing per-P pool capacity, which should reduce lock contention on
shared items. https://go-review.googlesource.com/c/go/+/49110 .
- Avoiding pool resets during GC
- https://gith
On Mon, Feb 19, 2018 at 4:56 AM, Chris Hopkins wrote:
>
> I would have expected the compiler to allowed to change:
> if len(l.shared) > 0 { # the racy check for non-emptiness
> l.Lock()
> last := len(l.shared) - 1
> to
> tmp := len(l.shared)
> if tmp > 0 { # the racy check for non-emptiness
>
I would have expected the compiler to allowed to change:
if len(l.shared) > 0 { # the racy check for non-emptiness
l.Lock()
last := len(l.shared) - 1
to
tmp := len(l.shared)
if tmp > 0 { # the racy check for non-emptiness
l.Lock()
last := tmp - 1
I'd be interested if this were a legal opti
Also, keep in mind, "being there nothing in the pool" is the common state
of pools immediately after every GC.
On Friday, February 16, 2018 at 12:05:27 PM UTC+9, Kevin Malachowski wrote:
>
> If there is likely nothing in the Pool, then maybe it's better to not use
> one at all. Can you compare t
Kevin,
We're already using pool only where it's not hurting performance (compared
to a bare new). I could probably come up with ad-hoc pools for specific
cases, but the approach I described in my previous mail seemed promising
because it makes Pool applicable also in cases where you put in less
If there is likely nothing in the Pool, then maybe it's better to not use
one at all. Can you compare the internal workload with an implementation
where all callers just call the `New` function directly? What's the purpose
of using a pooled memory if there's often nothing in the pool?
On Wednes
