ac27b4dd1d
The Grow method is generally a more efficient way to grow a slice. The older approach of using reflect.MakeSlice has to waste effort zeroing the elements overwritten by the older slice and has to allocate the slice header on the heap. Performance: name old time/op new time/op delta CodeDecoder 2.41ms ± 2% 2.42ms ± 2% ~ CodeUnmarshal 3.12ms ± 3% 3.13ms ± 3% ~ CodeUnmarshalReuse 2.49ms ± 3% 2.52ms ± 3% ~ name old alloc/op new alloc/op delta CodeDecoder 2.00MB ± 1% 1.99MB ± 1% ~ CodeUnmarshal 3.05MB ± 0% 2.92MB ± 0% -4.23% CodeUnmarshalReuse 1.68MB ± 0% 1.68MB ± 0% -0.32% name old allocs/op new allocs/op delta CodeDecoder 77.1k ± 0% 77.0k ± 0% -0.09% CodeUnmarshal 92.7k ± 0% 91.3k ± 0% -1.47% CodeUnmarshalReuse 77.1k ± 0% 77.0k ± 0% -0.07% The Code benchmarks (which are the only ones that uses slices) are largely unaffected. There is a slight reduction in allocations. A histogram of slice lengths from the Code testdata is as follows: ≤1: 392 ≤2: 256 ≤4: 252 ≤8: 152 ≤16: 126 ≤32: 78 ≤64: 62 ≤128: 46 ≤256: 18 ≤512: 10 ≤1024: 8 A bulk majority of slice lengths are 8 elements or under. Use of reflect.Value.Grow performs better for larger slices since it can avoid the zeroing of memory and has a faster growth rate. However, Grow grows starting from 1 element, with a 2x growth rate until some threshold (currently 512), Starting from 1 ensures better utilization of the heap, but at the cost of more frequent regrowth early on. In comparison, the previous logic always started with a minimum of 4 elements, which leads to a wasted capacity of 75% for the highly frequent case of a single element slice. The older code always had a growth rate of 1.5x, and so wastes less memory for number of elements below 512. All in all, there are too many factors that hurt or help performance. Rergardless, the simplicity of favoring reflect.Value.Grow over manually managing growth rates is a welcome simplification. Change-Id: I62868a7f112ece3c2da3b4f6bdf74d397110243c Reviewed-on: https://go-review.googlesource.com/c/go/+/471175 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> |
||
|---|---|---|
| .github | ||
| api | ||
| doc | ||
| lib/time | ||
| misc | ||
| src | ||
| test | ||
| .gitattributes | ||
| .gitignore | ||
| codereview.cfg | ||
| CONTRIBUTING.md | ||
| go.env | ||
| LICENSE | ||
| PATENTS | ||
| README.md | ||
| SECURITY.md | ||
The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 4.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Download and Install
Binary Distributions
Official binary distributions are available at https://go.dev/dl/.
After downloading a binary release, visit https://go.dev/doc/install for installation instructions.
Install From Source
If a binary distribution is not available for your combination of operating system and architecture, visit https://go.dev/doc/install/source for source installation instructions.
Contributing
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines at https://go.dev/doc/contribute.
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://go.dev/wiki/Questions for a list of places to ask questions about the Go language.