Thanks Peter, this is very interesting. Indeed I would not have
anticipated (though it makes some sense) that calling append would
outperform the manual loop, when the prefix is big, despite the overhead of
a builtin func call.
On Tuesday, August 22, 2017 at 7:22:42 PM UTC+2, peterGo wrote:
>
Val,
That's a lot of speculation!
The original benchmark applies to the original question:
prefix := verylongstring[:3]
If we change the parameters of the benchmark then we expect to get
different results. For example, read the Go gc compiler code. There's a
stack/heap optimization for 32
FWIW, append is most often a small performance penalty when the number of
elements is known ahead.
And for some reason, using built-in func copy, or an explicit loop, is
slightly faster on my workstation than BenchmarkConvert.
Also, "small benchmarks are hard" so I suspect the small allocations i
A benchmark;
https://play.golang.org/p/oUyeldDG5Q
$ cat strslice_test.go
package main
import (
"strings"
"testing"
)
var (
s = strings.Repeat("a very, very long string", 4096)
prefix string
)
func BenchmarkNil(b *testing.B) {
for i := 0; i < b.N; i++ {
prefix =
https://play.golang.org/p/YXXlJlsNGa
Hi,
i'm not sure if compiler is smart enough to optimize v1, but likely v2 ends
in separate memory.
On Tuesday, August 22, 2017 at 3:04:42 AM UTC+3, Travis Keep wrote:
>
> Suppose you have code like this
>
>
> // verylongstring may be several thousand b
