I think this part "Step 1) is not needed with the append approach, as we just reserve a memory location but the previous values stay there until we write them in step 2. " is not what the Go gc implementation currently actually does.<p>Copied from reddit: <a href="https://www.reddit.com/r/golang/comments/cn2jdh/benchmark_of_golang_slice_initialization_always/" rel="nofollow">https://www.reddit.com/r/golang/comments/cn2jdh/benchmark_of...</a><p>Currently make (runtime.makeslice or runtime.mallocgc or duffzero as part of stack allocation) always zeroes the backing array of slice regardless if the element is written to directly or append to the slice. Not requiring the memclr/zeroing would need a prove pass that proves that before the loop finishes noone can observe the uninitialized value by e.g. re-slicing. Which in general when e.g. interfaces and plugins are involved wont be possible to prove. In the case of pointers the memclr is also not avoidable since the garbage collector might scan that part of the memory (if its heap allocated) any time even while the loop is running. <a href="https://github.com/golang/go/blob/e37a1b1ca6afcbe3b02d2dfd599ad1d3d926ec34/src/runtime/slice.go#L49" rel="nofollow">https://github.com/golang/go/blob/e37a1b1ca6afcbe3b02d2dfd59...</a><p>There could be effects observed due to the difference of having small slices allocated on the stack vs on the heap and differing zero techniques. E.g. for size = 100 there is a jump to duffzero that clears the stack space for the backing array of the slice: <a href="https://godbolt.org/z/wRuF5z" rel="nofollow">https://godbolt.org/z/wRuF5z</a> while for size = 100000 the backing array is heap allocated and zeroed as part of the runtime.makeslice call.<p>There is a optimization fusing make+copy (to avoid the memclr) in the pipeline for go1.14 but this would not trigger here either.<a href="https://go-review.googlesource.com/c/go/+/146719" rel="nofollow">https://go-review.googlesource.com/c/go/+/146719</a>