On Wednesday, October 11, 2017 at 4:03:30 PM UTC-4, Ian Lance Taylor wrote: > > if the number of parallel operations does not vary > significantly, a freelist is a simpler and more effective technique. >
A freelist might be simpler, but it isn't necessarily more effective. sync.Pool combines two (non-orthogonal) properties: thread-local allocation and weak references. If the number of operations does not vary, the weak references don't matter much, but the thread-local allocation might. If many operations occur in parallel on a system with many CPU cores, a freelist can suffer from significant cache contention, whereas a sync.Pool generally will not. (See also https://golang.org/issue/18802.) That said, Go's allocator is fairly thread-local to begin with, so if you're explicitly zeroing out the objects before reusing them anyway, sync.Pool should provide very little benefit over simply allocating a new object for each operation. (That is especially true when the objects are small, and thus more likely to be satisfiable out of memory the thread has already obtained.) -- 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.
