Simple techniques to optimise Go programs

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 &amp;buf }} b := *bufpool.Get().(*[]byte) defer bufpool.Put(&amp;b) </code></pre> [0] see example in <a href="https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;sync&#x2F;#Pool" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;sync&#x2F;#Pool</a>

The JSON marshaler actually caches struct serializations so that you don&#x27;t incur the reflection cost on every run.

&gt; 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&#x27;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&#x27;s slower, and much less maintainable.<p>&gt; The safe way to ensure you always zero memory is to do so explicitly:<p><pre><code> &#x2F;&#x2F; reset resets all fields of the AuthenticationResponse before pooling it. func (a* AuthenticationResponse) reset() { a.Token = &quot;&quot; a.UserID = &quot;&quot; } </code></pre> I think this is safer, in face of modifications to the AuthenticationResponse structure, and much clearer in its intent:<p><pre><code> &#x2F;&#x2F; reset resets all fields of the AuthenticationResponse before pooling it. func (a* AuthenticationResponse) reset() { *a = AuthenticationResponse{} }</code></pre>

&gt; 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&#x27;t have to scan the entire heap on every collection.

&gt; In A&#x2F;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?

Replacing strings with ints would be more believable with a real world example.

&gt; 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&#x27;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.

For me, the best way to optimize a Go program is to write it in Rust.