Thx you both for your replies.

Just for sum up all stuff on sync.Pool, can I consider as true the
- sync.Pool is faster than channel due some improvement when we use
multi-processor machine
- with sync.Pool, you can't defined upper limit (unlike channel)
- with sync.Pool, buffer can be garbage collected even if there are stored
into sync.Pool (kind of java.lang.ref.WeakReference)

Le lundi 19 octobre 2015 05:28:15 UTC+2, Matt Silverlock a écrit :
There's also a discussion here about sync.Pool -

The most important thing to remember is that you MUST explicitly zero
objects you return (or get; either way) from the pool. Writing your own
convenience methods around the Get/Put methods will help to enforce that,
as well as the necessary type assertions.

Klaus Post's post on gzip writer pools also provides some useful example
code around using sync.Pool -
https://blog.klauspost.com/gzip-performance-for-go-webservers/ - and I
wrote an article not long ago on the channel-based approach:
On Monday, October 19, 2015 at 4:47:46 AM UTC+8, Dave Cheney wrote:

The latter is faster, but has the unfortunate requirement to smuggle
everything via an interface{}
On Monday, 19 October 2015 01:54:15 UTC+11, Jérôme LAFORGE wrote:


For implementing leaky buffer, you can do it :
- with channel (as descibe into
- or with sync.Pool.

Do you know if there is some difference on performance perspective (or
on others aspects) on this both choices?

Thx in adv.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 8 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 18, '15 at 2:54p
activeOct 20, '15 at 7:53a



site design / logo © 2022 Grokbase