I reviewed the code and it is still pretty inefficient compared to a local free list. I don’t think the single local element helps in the binary tree case anyway, as you are probably releasing branches of the tree at a time. Also, in the face of high cpu based concurrency/contention, the local instance quickly becomes not used. The prime use of sync.Pool appears to me to be reusing a buffer that can’t be stack allocated.
On Mar 8, 2019, at 1:24 AM, Sokolov Yura <funny.fal...@gmail.com> wrote: >> Unclear… revise… “it requires a lock & unlock for every get and put of an >> item" > > Not quite exactly. One item per scheduler (could be count as native thread) > is stored in fast thread local storage. Yes, there are still locks, but for > separate lock per thread, and this is quite cheap, since not contended. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
