6 ms·
I would mention that, gc (the official Go compiler) makes special optimization for string concatenation operation (+). If the number of strings to be concatenat
by tapirl 9y ago
I would mention that, gc (the official Go compiler) makes special optimization for string concatenation operation (+). If the number of strings to be concatenated is known at compile time, using + to concatenate strings is the most efficient.
package a
import "testing"
import "strings"
var strA, strB string
var x, y, z = "x", "y", "z"
func BenchmarkConcatString(b *testing.B) {
for n := 0; n < b.N; n++ {
strA = x + y + z
}
}
func BenchmarkConcatBuilder(b *testing.B) {
for n := 0; n < b.N; n++ {
var builder strings.Builder
builder.WriteString(x)
builder.WriteString(y)
builder.WriteString(z)
strB = builder.String()
}
}
Result:
goos: linux
goarch: amd64
BenchmarkConcatString-2 20000000 83.7 ns/op
BenchmarkConcatBuilder-2 20000000 102 ns/op
- foota 9y agoDoes Go intern strings? That could mess things up with this bench. edit: doesn't sound like it does by default
- BeeOnRope 9y agoNote that this is directly contradicted by another commnent[1] on this post, where three fixed strings are concatenated with +=, yet that was still slower. Perhaps the use of += as separate statements is the difference, but one would hope that gc wasn't so fragile as to be unable to identify those sequences as identical. --- [1] https://news.ycombinator.com/item?id=16533650 https://news.ycombinator.com/item?id=16533650
- lugg 9y agoI suspect / understood that as being the optimization is based on the fact that those are concatenated references and not string literals. I don't quite understand why string literals wouldn't be even easier to optimize but there it is.
- tapirl 9y agoThe optimization made by gc is only valid for the form: s0 + s1 + .... + sn.