Most of these techniques sacrifice readability so before implementing them, you should really profile to make sure that the code in question is a hot spot in terms of allocations or CPU usage.<p>That said, the example using sync.Pool is not quite right. The <i>New</i> function should always return a pointer type to avoid incurring an additional allocation on <i>Get</i> [0]<p>The code should look like:<p><pre><code> var bufpool = sync.Pool{
New: func() interface{} {
buf := make([]byte, 512)
return &buf
}}
b := *bufpool.Get().(*[]byte)
defer bufpool.Put(&b)
</code></pre>
[0] see example in <a href="https://golang.org/pkg/sync/#Pool" rel="nofollow">https://golang.org/pkg/sync/#Pool</a>
> a previous version of this blog post did not specify that the New() function should return a pointer type. This avoids an extra allocation when returning through the interface{} type.<p>While this is good advice, it's not entirely correct. Even with the current go compiler there are ways to use sync.Pool with non-pointer values without incurring in the extra allocation, e.g. using a second sync.Pool to reuse the interface{}. Although I would not recommend it as it's slower, and much less maintainable.<p>> The safe way to ensure you always zero memory is to do so explicitly:<p><pre><code> // reset resets all fields of the AuthenticationResponse before pooling it.
func (a* AuthenticationResponse) reset() {
a.Token = ""
a.UserID = ""
}
</code></pre>
I think this is safer, in face of modifications to the AuthenticationResponse structure, and much clearer in its intent:<p><pre><code> // reset resets all fields of the AuthenticationResponse before pooling it.
func (a* AuthenticationResponse) reset() {
*a = AuthenticationResponse{}
}</code></pre>
> During a garbage collection, the runtime scans objects containing pointers, and chases them. If you have a very large map[string]int, the GC has to check every string within the map, every GC, as strings contain pointers.<p>This would, of course, be much less of an issue with a generational GC, which doesn't have to scan the entire heap on every collection.
> In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue. - Greg Linden, Amazon.com<p>Just curious, do vendors on Amazon get reimbursed for the drops in revenue during tests like this?
> Allocate capacity in make to avoid re-allocation<p>Am I the only one who has done this and used append() within a loop, and resulted in a slice that is 2x as long as the original desired length, and the first 1x of items are all empty?<p>I quickly caught it and fixed the approach (instead of append, I used the `i` as the insertion index into my new empty slice which already had capacity allocated), but the ease with which that subtlety could be overlooked turned me off to this approach unless I profile and really find it's a hot path.<p>Edit to add: I tried his code, and it resulted in the new slice being as expected.
Missing technique: rewrite the performance-critical parts of your Go programs in a different language, and use Cgo to make them accessible to Go code via the standard C ABI. K.I.S.S.