In a highly concurrent system it can be difficult to know when to call Put if the object reference is shared among threads/routines. Similar to why C++ has shared pointers. It might be easy for the original author to know when a Put should be called but as a system grows and new functionality is added, it can become increasing difficult to perform manual reference counting - which is what you are doing...
> On Sep 27, 2018, at 9:06 AM, Peter Mogensen <a...@one.com> wrote: > > > >> On 09/27/2018 03:58 PM, Robert Engels wrote: >> 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... > > Well... being blissfully ignorant of JVM garbage collection pain.... I > occasionally use sync.Pool to improve code in Go with measurable > results. I've never really found it difficult to know when to call Put() > > I'm not that familiar with the GC issues around Go maps with pointers > though, but I can see that the difference between map[string]*Object and > map[int]int are not trivial for huge maps ... and I wondered whether you > really needed to pay the cost for using pointers if they came for a > sync.Pool anyway. > ... which seems like a rather common use case to me. > > /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.
