3 ms·
The last gotcha sort of leads to a different gotcha. That copy statement will only work as expected if the destination slice is large enough - thus always initi
by drej 9y ago
The last gotcha sort of leads to a different gotcha. That copy statement will only work as expected if the destination slice is large enough - thus always initialise it with the length of the (sub)slice you want to copy over. You won't get any errors if it's smaller, but you will surely not get what you desired.
- tapirl 9y agothe append way is much efficient than the make+copy way: https://github.com/go101/go-benchmarks/tree/master/append-vs-make https://github.com/go101/go-benchmarks/tree/master/append-vs...
- drej 9y agoNot sure it holds any more, I got these results $ go test -bench=. goos: darwin goarch: amd64 Benchmark_AllocWithMake-4 1000 1626664 ns/op Benchmark_AllocWithAppend-4 1000 1574720 ns/op
- seppoastian 9y agoI got nearly the same ratio as the github example. (CPU is overclock to ~4 GHz) $ cat /proc/cpuinfo | grep 'model name' | uniq model name: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz $ go version go version go1.9.1 windows/amd64 $ go test -bench . --benchtime 10s goos: windows goarch: amd64 Benchmark_AllocWithMake-12 20000 870349 ns/op Benchmark_AllocWithAppend-12 30000 561120 ns/op
- tapirl 9y agoPlease note that the Benchmark_AllocWithMake function even doesn't call "copy(y, x)".
- dilap 9y agoI am surprised that make would be slower than append! What's the explanation?