[go-nuts] Benchmarks of append vs copy

without doing to much cross-checking (I only use the second link for
reference), I also don't know a lot:
• You include the creation of the array in the timings. Use
   b.ResetTimer()
• I think you might also run into trouble with
   compiler-optimization. e.g. in BenchmarkAppendAllocInline{,NoFunc} I
   would think it is a valid optimization, to just do nothing at all in
   the loop (you don't do anything with init, and it is easily proven
   that it does not escape the loop, so there really is no need to change
   it at all). Check the generated assembly.
• You also include the make([]int64,…) in line 54 in the timings, which
   might or might not skew your result of preallocating
   vs. allocating. Then again, a literal compiler would need to
   initialize an array created with make to zeros, whereas the
   append-call doesn't need to do that… But then again, that should make
   the non-preallocate-method faster, not slower.
• I also think, that 1000 is a relatively small number. Have you
   experimented with larger numbers? That might (or might not) also skew
   your numbers or make them more random.

These are just random guesses though. Microbenchmarks like this are hard
to do right, imho, because unexpected side-effects like optimization
come stand in your way…

First, thanks for commenting on this. Your comments raise some good points.

Note the array is created once and the copy is done b.N times. So this
should be minor. But I did add this to the benchmark. It didn't make any
difference regarding the conclusions.

• I think you might also run into trouble with
I'm less interested in those cases, but if I crank the size of the slices
up to 10000, they fall in line with the results for the other cases. So it
doesn't seem likely it is being optimized away. I did worry about the same
issue though.

I'm only setting the capacity, not the size. So there shouldn't be any
initialization overhead...there is nothing to initialize.

I cranked it up to 10000. I also added the b.ResetTimer(). The basic
conclusion still holds. Using copy is about the same as doing
append([]int64{}, x...)

The specific cases I'm interested in were:

BenchmarkAppendAlloc 10000 203140 ns/op
BenchmarkCopy 10000 207800 ns/op


So the append version is slightly faster in this case.

These are just random guesses though. Microbenchmarks like this are hard
But the arrays are created out of scope (and given non-zero values) so I
don't see how anything could be optimized away (except in the cases you
pointed out where the result is thrown away).

So my conclusion would still be (after these expanded tests) that it
doesn't really matter whether you use copy or append.

Minor correction on this post. I cranked things up to 100,000, not 10,000.

Hi,

Michael Tiller <michael.tiller@gmail.com> writes:
Subslicing can access the underlying array out of the bounds of the
slice itself and obviously you can't check on every subslicing operation
if the array is initialized and do a lazy initialization (because
performance). So, the underlying array is initialized to zero, even if
the slice you take on it only covers parts of the array. e.g. in
http://play.golang.org/p/HVMhKRypHF
the underlying array is clearly initialized to zero.
Well, for example the compiler could inline doCopy, do constant folding
and decide, that it does not really need to do anything in the other
cases either. Not saying that this is happening, just that it might and
it is hard to say for sure, without looking at the generated machine
code. :)
Ah, in that I would agree. Apparently I missed that this was the point,
sorry. More generally you shouldn't worry about stuff like this, until
you have a real-world application with performance problems and it turns
out that one or the other is a bottleneck. :) The implementations of
append and copy clearly fall under "trust the compiler to do the right
thing, until proven otherwise" :)

Best,

Axel