It wasn’t necessarily a warning to you :) It comes from the days of GC bashing in Java and so everyone tried to manually write garbage free programs using pools and it had a bad effect on both performance and reliability. GC is there for a reason, use it... :) I would just hate to see Go developers “go” down the same path...
> On Sep 27, 2018, at 8:29 AM, Peter Mogensen <a...@one.com> wrote: > > > >> On 09/27/2018 03:25 PM, Robert Engels wrote: >> Based on my experience and I believe many others, I would caution against >> the use of pools. Although it can be useful for objects that are very >> expensive to create/initialize using it in a more general case just to >> improve GC can be fraught with issues in a highly concurrent and/or complex >> system. It is much more difficult to know when an object can be “put back” >> and be sure there are no more references. This is why there is GC in the >> first place, to avoid the types of bugs this leads to. > > regardless of the map GC issues, if one doesn't know when to call > Pool.Put(), one shouldn't use sync.Pool ... that's probably a given. > > But for the question at hand, let's assume that proper use of sync.Pool > is mastered. > > /Peter > > -- > 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.
