зеркало из https://github.com/github/vitess-gh.git
4d26cc1003
Using a strings.Builder over a bytes.Buffer yields one less allocation per call due to the final .String() call requring an allocation with bytes.Buffer, while strings.Builder is simply a pointer cast to a string. Also minor nits: * Iterating over the string bytes, rather than runes is quite a bit faster, and we don't care about runes. In general there are lots of places just glancing over the codebase that are using bytes.Buffer in places that I'm pretty confident could/should be converted over to strings.Builder instead. Constructing SQL strings, etc. These would all likely benefit from a decent performance boost, but I'm not entirely qualified to make these sweeping core changes in ways that I can't easily test. But they should be reasonably easy to audit and swap. They maintain the same API. Benchmark against main: ``` goos: linux goarch: amd64 pkg: vitess.io/vitess/go/sqlescape cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz BenchmarkEscapeID BenchmarkEscapeID/aa BenchmarkEscapeID/aa-8 13189527 122.3 ns/op 68 B/op 2 allocs/op BenchmarkEscapeID/a`a BenchmarkEscapeID/a`a-8 8941188 130.0 ns/op 72 B/op 2 allocs/op BenchmarkEscapeID/long BenchmarkEscapeID/long-8 659671 1661 ns/op 640 B/op 4 allocs/op PASS ``` Benchmark against my change: ``` goos: linux goarch: amd64 pkg: vitess.io/vitess/go/sqlescape cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz BenchmarkEscapeID BenchmarkEscapeID/aa BenchmarkEscapeID/aa-8 33748676 44.12 ns/op 8 B/op 1 allocs/op BenchmarkEscapeID/a`a BenchmarkEscapeID/a`a-8 26893474 48.27 ns/op 8 B/op 1 allocs/op BenchmarkEscapeID/long BenchmarkEscapeID/long-8 2717251 482.7 ns/op 160 B/op 1 allocs/op PASS ``` As we can see, the difference is actually about 3-4x, and on long strings, significantly better due to the pre-allocation. Signed-off-by: Matt Robenolt <matt@ydekproductions.com> |
||
|---|---|---|
| .. | ||
| ids.go | ||
| ids_test.go | ||