On Wed, Oct 11, 2017 at 12:50 PM, XXX ZZZ <emartinez1...@gmail.com> wrote: > > So I'm starting to play with sync pool on a program that needs to allocate a > ton of short lived objects per server request. Performance seems to be > better when using sync pool however I've noticed that upon releasing the > object and then retrieving it again, will produce a "new object" with "old > request data". The solution for this would be to reset the object > values/structs to 0, however I feel this will kinda defeat the purpose of > using sync pool. After all, we will always be creating new objects.
Yes, if you use sync.Pool, you must re-initialize any object you get from the pool, or you must restore any object you store in the pool back to the initial state. That is unavoidable. > Given that sync pool is used to avoid overhead when creating a lot of > elements, i would assume that I'm missing something here. Could anyone > please shred some light on this? That's not quite what sync.Pool is for. sync.Pool is useful for objects whose lifetime is bounded by a single operation, when there can be parallel operations, when the number of parallel operations varies significantly. In such a case sync.Pool provides a cache that lets you decrease allocation cost. It's just one technique for decreasing allocation cost, and there are several others. Most obviously, if the number of parallel operations does not vary significantly, a freelist is a simpler and more effective technique. 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.
