On Thu, Sep 4, 2014 at 1:57 PM, wrote:

I am wondering what the use cases of a sync.Pool could be in comparison to a
buffered channel?

The docs say that sync.Pool is used to "cache" output to stdio. I guess that
a sync.Pool may benefit here as it does not have a limit in size.

I still see two downsides on using sync.Pool over buffered channel:
1. Limiting the size via buffered channels may prevent memory problems
Pool can have arbitrary large size but at the same time do not cause
any memory problems. It is integrated with garbage collector.
2. Using select or for over a channel uses less resources then always
checking pool.Get() for non-nil values
I do not understand this.

On the other side I am sure the Go devs would not have added sync.Pool if
there would be no reason. So what am I missing?

Pool is faster and more scalable.
Pool do no retain memory unnecessarily, it's flushed during garbage collection.
Pool will autotune to required size. Consider that you have a
chan-based pool with capacity 10; if you have 20 goroutines; resources
will be constantly dropped and recreated. It won't happen with Pool.

The downside of Pool is that it can cache up to GOMAXPROCS more
objects than strictly necessary. If the objects are huge, it can be a

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 | 2 of 4 | next ›
Discussion Overview
groupgolang-nuts @
postedSep 4, '14 at 9:58a
activeSep 4, '14 at 11:29a

2 users in discussion

Dmitry Vyukov: 3 posts I: 1 post



site design / logo © 2021 Grokbase