On Fri, Oct 6, 2017 at 1:23 PM, XXX ZZZ <emartinez1...@gmail.com> wrote: > > So we are making a platform where we have to use a TON of short lived > structs, in order to optimize this we intend to use sync pool, however on > our benchmark tests I have found that it only seems to improve performance > when the struct is big enough, for smaller structs ie: (4-5 string values) > it seems to be considerably slower, yet I see many packages (such as > fasthttp) using sync pool for basically everything. Is there anything I am > missing? Any recommendations of when to use sync pool?
Be careful in your benchmarks. Make sure that the values are really being allocated, and not simply being stored on the stack by the compiler. Check how often the GC is running; allocation that does not trigger a GC is always going to be faster. Use sync.Pool when you have code that uses an unpredictable number of objects, where the allocation cost of the objects is noticeable compared to the cost of the rest of the code (either because the objects are large or because the rest of the code is fast), where you want to scale the allocation require based on the use of the package. Don't use sync.Pool if the number of objects is predictable: use a free list. Don't use it for basically everything; it won't actually save you any time. Use it for areas where the memory needs change unpredictably during the course of the program. Ian -- 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.
