mirror of https://github.com/golang/go.git
189 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
b46aec0765 |
bytes,internal/bytealg: eliminate HashStrBytes,HashStrRevBytes using …
…generics
The logic of HashStrBytes, HashStrRevBytes and HashStr, HashStrRev,
are exactly the same, except that the types are different.
Since the bootstrap toolchain is bumped to 1.20, we can eliminate them
by using generics.
Change-Id: I4336b1cab494ba963f09646c169b45f6b1ee62e3
GitHub-Last-Rev:
|
|
|
|
6dd7462a04 |
bytes,strings: add available godoc link
Change-Id: Id9706a783d3321e3706eeee102286522e7968efd Reviewed-on: https://go-review.googlesource.com/c/go/+/534775 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> |
|
|
|
8f61fab618 |
bytes,strings: add example for ContainsFunc
Change-Id: I340e892aa4ecc780905be984016efc86699a45a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/533556 Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> |
|
|
|
62fb281cf7 |
bytes, strings: use "reports whether" in HasPrefix and HasSuffix
Update the doc comments to use the more idiomatic and common phrase "reports whether" instead of "tests whether". Change-Id: I2b7f8cce2d192f66e296ebaa9b37f37e8276b4ae Reviewed-on: https://go-review.googlesource.com/c/go/+/524898 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> |
|
|
|
890a62bf1b |
internal/bytealg: add generic LastIndexByte{,String}
To avoid duplicating them in net/netip and os and to allow these
packages automatically benefiting from future performance improvements
when optimized native LastIndexByte{,String} implementations are added.
For #36891
Change-Id: I4905a4742273570c2c36b867df57762c5bfbe1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/522475
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
|
|
|
0163b3b32c |
all: remove redundant string conversions when formatting []byte with %s
Change-Id: I603051a3174b139ffb81d20d42979c7f3f04a09a Reviewed-on: https://go-review.googlesource.com/c/go/+/521136 Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> |
|
|
|
089e37a931 |
bytes: remove builders check from compare test
TestCompareBytes already took into account the -short testing flag, however, only if not run on one of the Go builders. This extra condition is no longer necessary as we have much better longtest coverage than we did when the check was added. Fixes #61071 Change-Id: I0fc716f4e7baa04019ee00608f223f27c931edcc Reviewed-on: https://go-review.googlesource.com/c/go/+/507416 Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> TryBot-Bypass: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
03cd8a7b0e |
internal/bytealg: fix alignment code in equal_riscv64.s
The riscv64 implementation of equal has an optimization that is applied when both pointers share the same alignment but that alignment is not 8 bytes. In this case it tries to align both pointers to an 8 byte boundaries, by individually comparing the first few bytes of each buffer. Unfortunately, the existing code is incorrect. It adjusts the pointers by the wrong number of bytes resulting, in most cases, in pointers that are not 8 byte aligned. This commit fixes the issue by individually comparing the first (8 - (pointer & 7)) bytes of each buffer rather than the first (pointer & 7) bytes. This particular optimization is not covered by any of the existing benchmarks so a new benchmark, BenchmarkEqualBothUnaligned, is provided. The benchmark tests the case where both pointers have the same alignment but may not be 8 byte aligned. Results of the new benchmark along with some of the existing benchmarks generated on a SiFive HiFive Unmatched A00 with 16GB of RAM running Ubuntu 23.04 are presented below. Equal/0-4 3.356n ± 0% 3.357n ± 0% ~ (p=0.840 n=10) Equal/1-4 63.91n ± 7% 65.97n ± 5% +3.22% (p=0.029 n=10) Equal/6-4 72.94n ± 5% 76.09n ± 4% ~ (p=0.075 n=10) Equal/9-4 84.61n ± 7% 85.83n ± 3% ~ (p=0.315 n=10) Equal/15-4 103.7n ± 2% 102.9n ± 4% ~ (p=0.739 n=10) Equal/16-4 89.14n ± 3% 100.40n ± 4% +12.64% (p=0.000 n=10) Equal/20-4 107.8n ± 3% 106.8n ± 3% ~ (p=0.725 n=10) Equal/32-4 63.95n ± 8% 67.79n ± 7% ~ (p=0.089 n=10) Equal/4K-4 1.256µ ± 1% 1.254µ ± 0% ~ (p=0.925 n=10) Equal/4M-4 1.231m ± 0% 1.230m ± 0% -0.04% (p=0.011 n=10) Equal/64M-4 19.77m ± 0% 19.78m ± 0% ~ (p=0.052 n=10) EqualBothUnaligned/64_0-4 43.70n ± 4% 44.40n ± 5% ~ (p=0.529 n=10) EqualBothUnaligned/64_1-4 6957.5n ± 0% 105.9n ± 1% -98.48% (p=0.000 n=10) EqualBothUnaligned/64_4-4 100.1n ± 2% 101.5n ± 4% ~ (p=0.149 n=10) EqualBothUnaligned/64_7-4 6965.00n ± 0% 95.60n ± 4% -98.63% (p=0.000 n=10) EqualBothUnaligned/4096_0-4 1.233µ ± 1% 1.225µ ± 0% -0.65% (p=0.015 n=10) EqualBothUnaligned/4096_1-4 584.226µ ± 0% 1.277µ ± 0% -99.78% (p=0.000 n=10) EqualBothUnaligned/4096_4-4 1.270µ ± 1% 1.268µ ± 0% ~ (p=0.105 n=10) EqualBothUnaligned/4096_7-4 584.944µ ± 0% 1.266µ ± 1% -99.78% (p=0.000 n=10) EqualBothUnaligned/4194304_0-4 1.241m ± 0% 1.236m ± 0% -0.38% (p=0.035 n=10) EqualBothUnaligned/4194304_1-4 600.956m ± 0% 1.238m ± 0% -99.79% (p=0.000 n=10) EqualBothUnaligned/4194304_4-4 1.239m ± 0% 1.241m ± 0% +0.22% (p=0.007 n=10) EqualBothUnaligned/4194304_7-4 601.036m ± 0% 1.239m ± 0% -99.79% (p=0.000 n=10) EqualBothUnaligned/67108864_0-4 19.79m ± 0% 19.78m ± 0% ~ (p=0.393 n=10) EqualBothUnaligned/67108864_1-4 9616.61m ± 0% 19.82m ± 0% -99.79% (p=0.000 n=10) EqualBothUnaligned/67108864_4-4 19.82m ± 0% 19.82m ± 0% ~ (p=0.971 n=10) EqualBothUnaligned/67108864_7-4 9616.34m ± 0% 19.86m ± 0% -99.79% (p=0.000 n=10) geomean 38.38µ 7.194µ -81.26% Change-Id: I4caab6c3450bd7e2773426b08b70bbc37fbe4e5f Reviewed-on: https://go-review.googlesource.com/c/go/+/500855 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> |
|
|
|
bfa25c3f6c |
internal/bytealg: fix alignment code in compare_riscv64.s
The riscv64 implementation of compare has an optimization that is applied when both pointers share the same alignment but that alignment is not 8 bytes. In this case it tries to align both pointers to an 8 byte boundaries, by individually comparing the first few bytes of each buffer. Unfortunately, the existing code is incorrect. It adjusts the pointers by the wrong number of bytes resulting, in most cases, in pointers that are not 8 byte aligned. This commit fixes the issue by individually comparing the first (8 - (pointer & 7)) bytes of each buffer rather than the first (pointer & 7) bytes. We also remove an unnecessary immediate MOV instruction. This particular optimization is not covered by any of the existing benchmarks so a new benchmark, benchmarkCompareBytesBigBothUnaligned, is provided. The benchmark tests the case where both pointers have the same alignment but may not be 8 byte aligned. Results of the new benchmark along with some of the existing benchmarks generated on a SiFive HiFive Unmatched A00 with 16GB of RAM running Ubuntu 23.04 are presented below. CompareBytesEqual-4 70.00n ± 6% 68.32n ± 0% -2.40% (p=0.020 n=10) CompareBytesToNil-4 19.31n ± 0% 18.47n ± 0% -4.35% (p=0.000 n=10) CompareBytesEmpty-4 16.79n ± 0% 15.95n ± 0% -4.97% (p=0.000 n=10) CompareBytesIdentical-4 19.94n ± 15% 18.32n ± 13% -8.15% (p=0.040 n=10) CompareBytesSameLength-4 37.93n ± 0% 42.44n ± 1% +11.91% (p=0.000 n=10) CompareBytesDifferentLength-4 37.93n ± 0% 42.44n ± 0% +11.89% (p=0.000 n=10) CompareBytesBigUnaligned/offset=1-4 3.881m ± 14% 3.880m ± 15% ~ (p=0.436 n=10) CompareBytesBigUnaligned/offset=2-4 3.884m ± 0% 3.875m ± 0% ~ (p=0.190 n=10) CompareBytesBigUnaligned/offset=3-4 3.858m ± 1% 3.868m ± 1% ~ (p=0.105 n=10) CompareBytesBigUnaligned/offset=4-4 3.877m ± 1% 3.876m ± 0% ~ (p=0.529 n=10) CompareBytesBigUnaligned/offset=5-4 3.859m ± 0% 3.874m ± 0% +0.39% (p=0.009 n=10) CompareBytesBigUnaligned/offset=6-4 3.878m ± 1% 3.876m ± 0% ~ (p=0.353 n=10) CompareBytesBigUnaligned/offset=7-4 3.868m ± 1% 3.877m ± 0% ~ (p=0.190 n=10) CompareBytesBigBothUnaligned/offset=0-4 1.586m ± 0% 1.765m ± 0% +11.30% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=1-4 153.132m ± 1% 1.765m ± 1% -98.85% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=2-4 152.930m ± 1% 1.765m ± 1% -98.85% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=3-4 152.093m ± 1% 1.769m ± 0% -98.84% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=4-4 1.602m ± 0% 1.764m ± 0% +10.11% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=5-4 152.314m ± 1% 1.768m ± 0% -98.84% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=6-4 152.905m ± 1% 1.764m ± 1% -98.85% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=7-4 152.951m ± 1% 1.804m ± 2% -98.82% (p=0.000 n=10) CompareBytesBig-4 1.441m ± 21% 1.373m ± 55% ~ (p=0.481 n=10) CompareBytesBigIdentical-4 19.94n ± 1% 19.10n ± 0% -4.21% (p=0.001 n=10) geomean 243.7µ 76.65µ -68.54% CompareBytesBigUnaligned/offset=1-4 257.7Mi ± 12% 257.7Mi ± 13% ~ (p=0.424 n=10) CompareBytesBigUnaligned/offset=2-4 257.5Mi ± 0% 258.1Mi ± 0% ~ (p=0.190 n=10) CompareBytesBigUnaligned/offset=3-4 259.2Mi ± 1% 258.5Mi ± 1% ~ (p=0.105 n=10) CompareBytesBigUnaligned/offset=4-4 257.9Mi ± 1% 258.0Mi ± 0% ~ (p=0.529 n=10) CompareBytesBigUnaligned/offset=5-4 259.1Mi ± 0% 258.1Mi ± 0% -0.39% (p=0.008 n=10) CompareBytesBigUnaligned/offset=6-4 257.9Mi ± 1% 258.0Mi ± 0% ~ (p=0.353 n=10) CompareBytesBigUnaligned/offset=7-4 258.5Mi ± 1% 257.9Mi ± 0% ~ (p=0.190 n=10) CompareBytesBigBothUnaligned/offset=0-4 630.6Mi ± 0% 566.6Mi ± 0% -10.15% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=1-4 6.533Mi ± 1% 566.545Mi ± 1% +8572.48% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=2-4 6.537Mi ± 1% 566.683Mi ± 1% +8568.27% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=3-4 6.576Mi ± 1% 565.200Mi ± 0% +8495.43% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=4-4 624.2Mi ± 0% 566.9Mi ± 0% -9.18% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=5-4 6.566Mi ± 1% 565.758Mi ± 0% +8516.41% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=6-4 6.542Mi ± 1% 567.036Mi ± 1% +8567.35% (p=0.000 n=10) CompareBytesBigBothUnaligned/offset=7-4 6.542Mi ± 1% 554.390Mi ± 2% +8374.05% (p=0.000 n=10) CompareBytesBig-4 694.2Mi ± 18% 728.1Mi ± 35% ~ (p=0.481 n=10) CompareBytesBigIdentical-4 47.83Ti ± 1% 49.92Ti ± 0% +4.39% (p=0.002 n=10) geomean 170.0Mi 813.8Mi +378.66% Change-Id: I0a2d0386d5ca1ffa249682a12ebd1533508e31e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/497838 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: M Zhuo <mzh@golangcn.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: M Zhuo <mzh@golangcn.org> |
|
|
|
9d35ebba06 |
std: fix various nilness findings
Found by running $ go run golang.org/x/tools/go/analysis/passes/nilness/cmd/nilness@latest std No actual bugs--other than one panic(nil)--but a few places where error nilness was unclear. Change-Id: Ia916ba30f46f29c1bcf928cc62280169b922463a Reviewed-on: https://go-review.googlesource.com/c/go/+/486675 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Alan Donovan <adonovan@google.com> |
|
|
|
d8d22664c6 |
all: fix misuses of "a" vs "an"
Fixes the misuse of "a" vs "an", according to English grammatical expectations and using https://www.a-or-an.com/ Change-Id: I53ac724070e3ff3d33c304483fe72c023c7cda47 Reviewed-on: https://go-review.googlesource.com/c/go/+/480536 Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> |
|
|
|
9768f736ea |
all: add a few links in package godocs
I noticed the one in path/filepath while reading the docs, and the other ones were found via some quick grepping. Change-Id: I386f2f74ef816a6d18aa2f58ee6b64dbd0147c9e Reviewed-on: https://go-review.googlesource.com/c/go/+/478795 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
e671fe0c3e |
bytes: add Buffer.Available and Buffer.AvailableBuffer
This adds a new Buffer.AvailableBuffer method that returns an empty buffer with a possibly non-empty capacity for use with append-like APIs. The typical usage pattern is something like: b := bb.AvailableBuffer() b = appendValue(b, v) bb.Write(b) It allows logic combining append-like APIs with Buffer to avoid needing to allocate and manage buffers themselves and allows the append-like APIs to directly write into the Buffer. The Buffer.Write method uses the builtin copy function, which avoids copying bytes if the source and destination are identical. Thus, Buffer.Write is a constant-time call for this pattern. Performance: BenchmarkBufferAppendNoCopy 2.909 ns/op 5766942167.24 MB/s This benchmark should only be testing the cost of bookkeeping and never the copying of the input slice. Thus, the MB/s should be orders of magnitude faster than RAM. Fixes #53685 Change-Id: I0b41e54361339df309db8d03527689b123f99085 Reviewed-on: https://go-review.googlesource.com/c/go/+/474635 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
132fae93b7 |
bytes, strings: avoid unnecessary zero initialization
Add bytealg.MakeNoZero that specially allocates a []byte without zeroing it. It assumes the caller will populate every byte. From within the bytes and strings packages, we can use bytealg.MakeNoZero in a way where our logic ensures that the entire slice is overwritten such that uninitialized bytes are never leaked to the end user. We use bytealg.MakeNoZero from within the following functions: * bytes.Join * bytes.Repeat * bytes.ToUpper * bytes.ToLower * strings.Builder.Grow The optimization in strings.Builder transitively benefits the following: * strings.Join * strings.Map * strings.Repeat * strings.ToUpper * strings.ToLower * strings.ToValidUTF8 * strings.Replace * any user logic that depends on strings.Builder This optimization is especially notable on large buffers that do not fit in the CPU cache, such that the cost of runtime.memclr and runtime.memmove are non-trivial since they are both limited by the relatively slow speed of physical RAM. Performance: RepeatLarge/256/1 66.0ns ± 3% 64.5ns ± 1% ~ (p=0.095 n=5+5) RepeatLarge/256/16 55.4ns ± 5% 53.1ns ± 3% -4.17% (p=0.016 n=5+5) RepeatLarge/512/1 95.5ns ± 7% 87.1ns ± 2% -8.78% (p=0.008 n=5+5) RepeatLarge/512/16 84.4ns ± 9% 76.2ns ± 5% -9.73% (p=0.016 n=5+5) RepeatLarge/1024/1 161ns ± 4% 144ns ± 7% -10.45% (p=0.016 n=5+5) RepeatLarge/1024/16 148ns ± 3% 141ns ± 5% ~ (p=0.095 n=5+5) RepeatLarge/2048/1 296ns ± 7% 288ns ± 5% ~ (p=0.841 n=5+5) RepeatLarge/2048/16 298ns ± 8% 281ns ± 5% ~ (p=0.151 n=5+5) RepeatLarge/4096/1 593ns ± 8% 539ns ± 8% -8.99% (p=0.032 n=5+5) RepeatLarge/4096/16 568ns ±12% 526ns ± 7% ~ (p=0.056 n=5+5) RepeatLarge/8192/1 1.15µs ± 8% 1.08µs ±12% ~ (p=0.095 n=5+5) RepeatLarge/8192/16 1.12µs ± 4% 1.07µs ± 7% ~ (p=0.310 n=5+5) RepeatLarge/8192/4097 1.77ns ± 1% 1.76ns ± 2% ~ (p=0.310 n=5+5) RepeatLarge/16384/1 2.06µs ± 7% 1.94µs ± 5% ~ (p=0.222 n=5+5) RepeatLarge/16384/16 2.02µs ± 4% 1.92µs ± 6% ~ (p=0.095 n=5+5) RepeatLarge/16384/4097 1.50µs ±15% 1.44µs ±11% ~ (p=0.802 n=5+5) RepeatLarge/32768/1 3.90µs ± 8% 3.65µs ±11% ~ (p=0.151 n=5+5) RepeatLarge/32768/16 3.92µs ±14% 3.68µs ±12% ~ (p=0.222 n=5+5) RepeatLarge/32768/4097 3.71µs ± 5% 3.43µs ± 4% -7.54% (p=0.032 n=5+5) RepeatLarge/65536/1 7.47µs ± 8% 6.88µs ± 9% ~ (p=0.056 n=5+5) RepeatLarge/65536/16 7.29µs ± 4% 6.74µs ± 6% -7.60% (p=0.016 n=5+5) RepeatLarge/65536/4097 7.90µs ±11% 6.34µs ± 5% -19.81% (p=0.008 n=5+5) RepeatLarge/131072/1 17.0µs ±18% 14.1µs ± 6% -17.32% (p=0.008 n=5+5) RepeatLarge/131072/16 15.2µs ± 2% 16.2µs ±17% ~ (p=0.151 n=5+5) RepeatLarge/131072/4097 15.7µs ± 6% 14.8µs ±11% ~ (p=0.095 n=5+5) RepeatLarge/262144/1 30.4µs ± 5% 31.4µs ±13% ~ (p=0.548 n=5+5) RepeatLarge/262144/16 30.1µs ± 4% 30.7µs ±11% ~ (p=1.000 n=5+5) RepeatLarge/262144/4097 31.2µs ± 7% 32.7µs ±13% ~ (p=0.310 n=5+5) RepeatLarge/524288/1 67.5µs ± 9% 63.7µs ± 3% ~ (p=0.095 n=5+5) RepeatLarge/524288/16 67.2µs ± 5% 62.9µs ± 6% ~ (p=0.151 n=5+5) RepeatLarge/524288/4097 65.5µs ± 4% 65.2µs ±18% ~ (p=0.548 n=5+5) RepeatLarge/1048576/1 141µs ± 6% 137µs ±14% ~ (p=0.421 n=5+5) RepeatLarge/1048576/16 140µs ± 2% 134µs ±11% ~ (p=0.222 n=5+5) RepeatLarge/1048576/4097 141µs ± 3% 134µs ±10% ~ (p=0.151 n=5+5) RepeatLarge/2097152/1 258µs ± 2% 271µs ±10% ~ (p=0.222 n=5+5) RepeatLarge/2097152/16 263µs ± 6% 273µs ± 9% ~ (p=0.151 n=5+5) RepeatLarge/2097152/4097 270µs ± 2% 277µs ± 6% ~ (p=0.690 n=5+5) RepeatLarge/4194304/1 684µs ± 3% 467µs ± 6% -31.69% (p=0.008 n=5+5) RepeatLarge/4194304/16 682µs ± 1% 471µs ± 7% -30.91% (p=0.008 n=5+5) RepeatLarge/4194304/4097 685µs ± 2% 465µs ±20% -32.12% (p=0.008 n=5+5) RepeatLarge/8388608/1 1.50ms ± 1% 1.16ms ± 8% -22.63% (p=0.008 n=5+5) RepeatLarge/8388608/16 1.50ms ± 2% 1.22ms ±17% -18.49% (p=0.008 n=5+5) RepeatLarge/8388608/4097 1.51ms ± 7% 1.33ms ±11% -11.56% (p=0.008 n=5+5) RepeatLarge/16777216/1 3.48ms ± 4% 2.66ms ±13% -23.76% (p=0.008 n=5+5) RepeatLarge/16777216/16 3.37ms ± 3% 2.57ms ±13% -23.72% (p=0.008 n=5+5) RepeatLarge/16777216/4097 3.38ms ± 9% 2.50ms ±11% -26.16% (p=0.008 n=5+5) RepeatLarge/33554432/1 7.74ms ± 1% 4.70ms ±19% -39.31% (p=0.016 n=4+5) RepeatLarge/33554432/16 7.90ms ± 4% 4.78ms ± 9% -39.50% (p=0.008 n=5+5) RepeatLarge/33554432/4097 7.80ms ± 2% 4.86ms ±11% -37.60% (p=0.008 n=5+5) RepeatLarge/67108864/1 16.4ms ± 3% 9.7ms ±15% -41.29% (p=0.008 n=5+5) RepeatLarge/67108864/16 16.5ms ± 1% 9.9ms ±15% -39.83% (p=0.008 n=5+5) RepeatLarge/67108864/4097 16.5ms ± 1% 11.0ms ±18% -32.95% (p=0.008 n=5+5) RepeatLarge/134217728/1 35.2ms ±12% 19.2ms ±10% -45.58% (p=0.008 n=5+5) RepeatLarge/134217728/16 34.6ms ± 6% 19.3ms ± 7% -44.07% (p=0.008 n=5+5) RepeatLarge/134217728/4097 33.2ms ± 2% 19.3ms ±14% -41.79% (p=0.008 n=5+5) RepeatLarge/268435456/1 70.9ms ± 2% 36.2ms ± 5% -48.87% (p=0.008 n=5+5) RepeatLarge/268435456/16 77.4ms ± 7% 36.1ms ± 8% -53.33% (p=0.008 n=5+5) RepeatLarge/268435456/4097 75.8ms ± 4% 37.0ms ± 4% -51.15% (p=0.008 n=5+5) RepeatLarge/536870912/1 163ms ±14% 77ms ± 9% -52.94% (p=0.008 n=5+5) RepeatLarge/536870912/16 156ms ± 4% 76ms ± 6% -51.42% (p=0.008 n=5+5) RepeatLarge/536870912/4097 151ms ± 2% 76ms ± 6% -49.64% (p=0.008 n=5+5) RepeatLarge/1073741824/1 293ms ± 5% 149ms ± 8% -49.18% (p=0.008 n=5+5) RepeatLarge/1073741824/16 308ms ± 9% 150ms ± 8% -51.19% (p=0.008 n=5+5) RepeatLarge/1073741824/4097 299ms ± 5% 151ms ± 6% -49.51% (p=0.008 n=5+5) Updates #57153 Change-Id: I024553b7e676d6da6408278109ac1fa8def0a802 Reviewed-on: https://go-review.googlesource.com/c/go/+/456336 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> |
|
|
|
0b3f58c48e |
bytes, strings: add ContainsFunc
Fixes #54386. Change-Id: I78747da337ed6129e4f7426dd0483a644bed82e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/460216 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: hopehook <hopehook@golangcn.org> Auto-Submit: Ian Lance Taylor <iant@golang.org> |
|
|
|
85b49d7f21 |
bytes,strings: add some examples
Change-Id: Ic93ad59119f3549c0f13c4f366f71e9d01b88c47
GitHub-Last-Rev:
|
|
|
|
e590afcf2c |
bytes, strings: rename field in CutSuffix tests
Change-Id: I63181f6540fc1bfcfc988a16bf9fafbd3575cfdf
GitHub-Last-Rev:
|
|
|
|
dcb90152a4 |
bytes,strings: optimize Repeat
When generating long strings or slices with Repeat we currently reuse intermediate states as a way to quickly build exponentially longer results. This works well as long as the intermediate states fit into the processor D-cache. If they don't we start thrashing the D-cache by reading in the whole intermediate state over and over on each iteration. Instead, once we reach a large enough intermediate state (that allows the memcpy operation to perform at peak) we cap the size of chunk of the state that is used as source for subsequent appends. This ensures that this smaller source chunk is always present in the D-cache, and the append operation does not need to read the state contents from memory. Currently the cap is set to 8KB, a number derived via experimentation to yield the highest performance across a a large range of result sizes. Slightly higher caps also produced similar results: 8KB was chosen as the smallest one in this performance plateau with the intention to minimize D-cache pollution. For result sizes larger than the fastest cache levels we get significantly higher performance compared to the current implementation: strings: name old speed new speed delta RepeatLarge/256/1-16 1.73GB/s ± 1% 1.73GB/s ± 0% ~ (p=0.556 n=5+4) RepeatLarge/256/16-16 2.02GB/s ± 0% 1.95GB/s ± 8% ~ (p=0.222 n=5+5) RepeatLarge/512/1-16 2.30GB/s ±13% 2.47GB/s ± 1% ~ (p=0.548 n=5+5) RepeatLarge/512/16-16 2.38GB/s ±16% 2.77GB/s ± 1% +16.27% (p=0.032 n=5+5) RepeatLarge/1024/1-16 3.17GB/s ± 1% 3.18GB/s ± 0% ~ (p=0.730 n=4+5) RepeatLarge/1024/16-16 3.39GB/s ± 2% 3.38GB/s ± 1% ~ (p=0.548 n=5+5) RepeatLarge/2048/1-16 3.32GB/s ± 2% 3.32GB/s ± 2% ~ (p=1.000 n=5+5) RepeatLarge/2048/16-16 3.41GB/s ± 4% 3.46GB/s ± 2% ~ (p=0.310 n=5+5) RepeatLarge/4096/1-16 3.60GB/s ± 4% 3.67GB/s ± 3% ~ (p=0.690 n=5+5) RepeatLarge/4096/16-16 3.74GB/s ± 3% 3.71GB/s ± 5% ~ (p=0.690 n=5+5) RepeatLarge/8192/1-16 3.94GB/s ± 4% 4.01GB/s ± 1% ~ (p=0.222 n=5+5) RepeatLarge/8192/16-16 3.94GB/s ± 6% 4.05GB/s ± 1% ~ (p=0.222 n=5+5) RepeatLarge/8192/4097-16 4.25GB/s ± 6% 4.32GB/s ± 3% ~ (p=0.690 n=5+5) RepeatLarge/16384/1-16 4.96GB/s ± 1% 5.02GB/s ± 2% ~ (p=0.421 n=5+5) RepeatLarge/16384/16-16 4.99GB/s ± 2% 5.07GB/s ± 1% ~ (p=0.421 n=5+5) RepeatLarge/16384/4097-16 5.15GB/s ± 3% 5.17GB/s ± 1% ~ (p=1.000 n=5+5) RepeatLarge/32768/1-16 5.44GB/s ± 2% 5.42GB/s ± 1% ~ (p=0.841 n=5+5) RepeatLarge/32768/16-16 5.46GB/s ± 4% 5.44GB/s ± 1% ~ (p=0.905 n=5+4) RepeatLarge/32768/4097-16 4.84GB/s ± 2% 4.59GB/s ±12% -5.05% (p=0.032 n=5+5) RepeatLarge/65536/1-16 5.85GB/s ± 0% 5.84GB/s ± 1% ~ (p=0.690 n=5+5) RepeatLarge/65536/16-16 5.81GB/s ± 2% 5.84GB/s ± 2% ~ (p=0.421 n=5+5) RepeatLarge/65536/4097-16 5.38GB/s ± 6% 5.45GB/s ± 1% ~ (p=1.000 n=5+5) RepeatLarge/131072/1-16 6.20GB/s ± 1% 6.31GB/s ± 1% +1.80% (p=0.008 n=5+5) RepeatLarge/131072/16-16 6.12GB/s ± 3% 6.25GB/s ± 3% ~ (p=0.095 n=5+5) RepeatLarge/131072/4097-16 5.95GB/s ± 1% 5.85GB/s ±10% ~ (p=1.000 n=5+5) RepeatLarge/262144/1-16 6.33GB/s ± 1% 6.56GB/s ± 0% +3.62% (p=0.016 n=5+4) RepeatLarge/262144/16-16 6.42GB/s ± 0% 6.65GB/s ± 1% +3.58% (p=0.016 n=4+5) RepeatLarge/262144/4097-16 6.31GB/s ± 1% 6.44GB/s ± 1% +1.94% (p=0.008 n=5+5) RepeatLarge/524288/1-16 6.23GB/s ± 1% 6.92GB/s ± 3% +11.02% (p=0.008 n=5+5) RepeatLarge/524288/16-16 6.24GB/s ± 1% 6.97GB/s ± 2% +11.77% (p=0.016 n=4+5) RepeatLarge/524288/4097-16 6.14GB/s ± 2% 6.73GB/s ± 3% +9.50% (p=0.008 n=5+5) RepeatLarge/1048576/1-16 5.23GB/s ± 1% 6.53GB/s ± 6% +24.85% (p=0.008 n=5+5) RepeatLarge/1048576/16-16 5.21GB/s ± 1% 6.56GB/s ± 4% +25.93% (p=0.008 n=5+5) RepeatLarge/1048576/4097-16 5.22GB/s ± 1% 6.26GB/s ± 2% +20.09% (p=0.008 n=5+5) RepeatLarge/2097152/1-16 3.95GB/s ± 1% 5.96GB/s ± 1% +51.01% (p=0.008 n=5+5) RepeatLarge/2097152/16-16 3.94GB/s ± 1% 5.98GB/s ± 2% +51.99% (p=0.008 n=5+5) RepeatLarge/2097152/4097-16 4.94GB/s ± 1% 5.71GB/s ± 2% +15.63% (p=0.008 n=5+5) RepeatLarge/4194304/1-16 3.10GB/s ± 1% 5.89GB/s ± 1% +89.90% (p=0.008 n=5+5) RepeatLarge/4194304/16-16 3.09GB/s ± 1% 5.86GB/s ± 1% +89.89% (p=0.008 n=5+5) RepeatLarge/4194304/4097-16 3.13GB/s ± 1% 5.89GB/s ± 1% +88.36% (p=0.008 n=5+5) RepeatLarge/8388608/1-16 3.06GB/s ± 1% 6.31GB/s ±16% +105.84% (p=0.008 n=5+5) RepeatLarge/8388608/16-16 3.08GB/s ± 1% 6.62GB/s ± 1% +114.66% (p=0.008 n=5+5) RepeatLarge/8388608/4097-16 3.13GB/s ± 2% 6.87GB/s ± 1% +119.62% (p=0.008 n=5+5) RepeatLarge/16777216/1-16 3.21GB/s ± 3% 5.88GB/s ± 1% +83.27% (p=0.008 n=5+5) RepeatLarge/16777216/16-16 3.23GB/s ± 2% 5.84GB/s ± 2% +80.49% (p=0.008 n=5+5) RepeatLarge/16777216/4097-16 3.30GB/s ± 6% 5.88GB/s ± 2% +78.18% (p=0.008 n=5+5) RepeatLarge/33554432/1-16 3.71GB/s ± 3% 5.91GB/s ± 2% +59.17% (p=0.008 n=5+5) RepeatLarge/33554432/16-16 3.67GB/s ± 3% 5.91GB/s ± 2% +61.13% (p=0.008 n=5+5) RepeatLarge/33554432/4097-16 3.71GB/s ± 1% 5.77GB/s ± 6% +55.51% (p=0.008 n=5+5) RepeatLarge/67108864/1-16 4.61GB/s ±11% 6.00GB/s ± 5% +30.15% (p=0.008 n=5+5) RepeatLarge/67108864/16-16 4.62GB/s ± 7% 6.11GB/s ± 2% +32.35% (p=0.008 n=5+5) RepeatLarge/67108864/4097-16 4.71GB/s ± 2% 6.24GB/s ± 2% +32.60% (p=0.008 n=5+5) RepeatLarge/134217728/1-16 4.53GB/s ± 8% 6.28GB/s ±11% +38.57% (p=0.008 n=5+5) RepeatLarge/134217728/16-16 4.78GB/s ± 3% 6.36GB/s ± 3% +33.16% (p=0.008 n=5+5) RepeatLarge/134217728/4097-16 4.73GB/s ± 6% 6.46GB/s ± 3% +36.63% (p=0.008 n=5+5) RepeatLarge/268435456/1-16 4.09GB/s ±25% 6.37GB/s ±19% +56.00% (p=0.008 n=5+5) RepeatLarge/268435456/16-16 4.50GB/s ± 4% 6.86GB/s ± 0% +52.49% (p=0.016 n=5+4) RepeatLarge/268435456/4097-16 4.73GB/s ± 5% 6.90GB/s ± 0% +45.94% (p=0.008 n=5+5) RepeatLarge/536870912/1-16 4.38GB/s ±36% 6.52GB/s ± 8% +48.68% (p=0.008 n=5+5) RepeatLarge/536870912/16-16 4.69GB/s ±12% 6.90GB/s ± 1% +46.97% (p=0.008 n=5+5) RepeatLarge/536870912/4097-16 4.87GB/s ± 8% 6.98GB/s ± 0% +43.36% (p=0.008 n=5+5) RepeatLarge/1073741824/1-16 3.87GB/s ±28% 6.96GB/s ± 1% +79.94% (p=0.016 n=5+4) RepeatLarge/1073741824/16-16 4.79GB/s ± 9% 6.93GB/s ± 0% +44.79% (p=0.008 n=5+5) RepeatLarge/1073741824/4097-16 4.65GB/s ± 8% 7.02GB/s ± 1% +51.02% (p=0.008 n=5+5) bytes: name old speed new speed delta RepeatLarge/256/1-16 1.93GB/s ± 1% 1.84GB/s ± 1% -4.81% (p=0.000 n=10+10) RepeatLarge/256/16-16 2.25GB/s ± 2% 2.15GB/s ± 1% -4.45% (p=0.000 n=9+8) RepeatLarge/512/1-16 2.71GB/s ± 1% 2.62GB/s ± 1% -3.27% (p=0.000 n=10+9) RepeatLarge/512/16-16 2.96GB/s ± 4% 2.91GB/s ± 1% ~ (p=0.243 n=9+10) RepeatLarge/1024/1-16 3.35GB/s ± 1% 3.27GB/s ± 1% -2.61% (p=0.000 n=9+10) RepeatLarge/1024/16-16 3.56GB/s ± 2% 3.52GB/s ± 1% -1.10% (p=0.010 n=10+9) RepeatLarge/2048/1-16 3.52GB/s ± 1% 3.45GB/s ± 1% -1.92% (p=0.000 n=10+10) RepeatLarge/2048/16-16 3.61GB/s ± 1% 3.58GB/s ± 0% -0.82% (p=0.008 n=9+8) RepeatLarge/4096/1-16 3.85GB/s ± 2% 3.80GB/s ± 2% ~ (p=0.165 n=10+10) RepeatLarge/4096/16-16 3.88GB/s ± 3% 3.84GB/s ± 4% ~ (p=0.393 n=10+10) RepeatLarge/8192/1-16 4.12GB/s ± 2% 4.04GB/s ± 1% -1.96% (p=0.000 n=10+10) RepeatLarge/8192/16-16 4.11GB/s ± 2% 4.09GB/s ± 1% ~ (p=0.278 n=9+10) RepeatLarge/8192/4097-16 4.38GB/s ± 1% 4.39GB/s ± 4% ~ (p=0.720 n=9+10) RepeatLarge/16384/1-16 5.06GB/s ± 2% 4.95GB/s ± 3% -2.29% (p=0.001 n=10+9) RepeatLarge/16384/16-16 5.11GB/s ± 3% 5.06GB/s ± 3% ~ (p=0.315 n=10+9) RepeatLarge/16384/4097-16 5.22GB/s ± 3% 5.26GB/s ± 3% ~ (p=0.211 n=9+10) RepeatLarge/32768/1-16 5.54GB/s ± 2% 5.50GB/s ± 3% ~ (p=0.353 n=10+10) RepeatLarge/32768/16-16 5.55GB/s ± 1% 5.60GB/s ± 1% +0.91% (p=0.035 n=10+9) RepeatLarge/32768/4097-16 4.88GB/s ± 2% 4.85GB/s ± 2% ~ (p=0.447 n=10+9) RepeatLarge/65536/1-16 5.86GB/s ± 1% 5.93GB/s ± 2% +1.18% (p=0.043 n=8+10) RepeatLarge/65536/16-16 5.83GB/s ± 2% 5.98GB/s ± 1% +2.67% (p=0.000 n=10+10) RepeatLarge/65536/4097-16 5.57GB/s ± 0% 5.56GB/s ± 3% ~ (p=0.696 n=8+10) RepeatLarge/131072/1-16 6.23GB/s ± 1% 6.38GB/s ± 2% +2.51% (p=0.000 n=9+10) RepeatLarge/131072/16-16 6.21GB/s ± 2% 6.37GB/s ± 1% +2.72% (p=0.000 n=9+10) RepeatLarge/131072/4097-16 6.04GB/s ± 1% 6.09GB/s ± 3% ~ (p=0.356 n=9+10) RepeatLarge/262144/1-16 6.47GB/s ± 1% 6.63GB/s ± 2% +2.57% (p=0.003 n=10+10) RepeatLarge/262144/16-16 6.45GB/s ± 2% 6.69GB/s ± 2% +3.65% (p=0.000 n=10+10) RepeatLarge/262144/4097-16 6.35GB/s ± 1% 6.51GB/s ± 2% +2.48% (p=0.000 n=9+10) RepeatLarge/524288/1-16 6.21GB/s ± 2% 6.95GB/s ± 1% +11.95% (p=0.000 n=10+10) RepeatLarge/524288/16-16 6.24GB/s ± 2% 6.93GB/s ± 2% +11.11% (p=0.000 n=10+10) RepeatLarge/524288/4097-16 6.18GB/s ± 2% 6.82GB/s ± 1% +10.39% (p=0.000 n=9+10) RepeatLarge/1048576/1-16 5.34GB/s ± 2% 6.41GB/s ± 2% +20.05% (p=0.000 n=10+10) RepeatLarge/1048576/16-16 5.33GB/s ± 1% 6.45GB/s ± 2% +20.84% (p=0.000 n=10+9) RepeatLarge/1048576/4097-16 5.28GB/s ± 1% 6.17GB/s ± 2% +16.75% (p=0.000 n=10+10) RepeatLarge/2097152/1-16 4.04GB/s ± 1% 6.21GB/s ± 1% +53.89% (p=0.000 n=9+8) RepeatLarge/2097152/16-16 4.02GB/s ± 1% 6.20GB/s ± 2% +54.37% (p=0.000 n=10+9) RepeatLarge/2097152/4097-16 4.94GB/s ± 1% 6.04GB/s ± 1% +22.36% (p=0.000 n=10+10) RepeatLarge/4194304/1-16 3.10GB/s ± 1% 5.74GB/s ± 0% +85.04% (p=0.000 n=10+9) RepeatLarge/4194304/16-16 3.10GB/s ± 2% 5.72GB/s ± 1% +84.26% (p=0.000 n=9+10) RepeatLarge/4194304/4097-16 3.03GB/s ± 4% 5.61GB/s ± 1% +85.06% (p=0.000 n=10+9) RepeatLarge/8388608/1-16 3.08GB/s ± 2% 6.25GB/s ± 1% +103.09% (p=0.000 n=9+9) RepeatLarge/8388608/16-16 3.07GB/s ± 2% 6.26GB/s ± 3% +104.07% (p=0.000 n=10+9) RepeatLarge/8388608/4097-16 3.08GB/s ± 2% 6.23GB/s ± 2% +102.09% (p=0.000 n=9+10) RepeatLarge/16777216/1-16 3.25GB/s ± 2% 5.78GB/s ± 3% +78.03% (p=0.000 n=9+9) RepeatLarge/16777216/16-16 3.25GB/s ± 1% 5.75GB/s ± 1% +77.21% (p=0.000 n=9+10) RepeatLarge/16777216/4097-16 3.29GB/s ± 3% 5.72GB/s ± 2% +73.74% (p=0.000 n=10+10) RepeatLarge/33554432/1-16 3.68GB/s ± 2% 5.90GB/s ± 1% +60.20% (p=0.000 n=10+10) RepeatLarge/33554432/16-16 3.69GB/s ± 3% 5.88GB/s ± 1% +59.54% (p=0.000 n=10+9) RepeatLarge/33554432/4097-16 3.74GB/s ± 1% 5.94GB/s ± 2% +58.68% (p=0.000 n=7+10) RepeatLarge/67108864/1-16 4.62GB/s ±12% 6.11GB/s ± 3% +32.23% (p=0.000 n=10+9) RepeatLarge/67108864/16-16 4.77GB/s ± 2% 6.09GB/s ± 2% +27.88% (p=0.000 n=9+9) RepeatLarge/67108864/4097-16 4.78GB/s ± 1% 6.19GB/s ± 1% +29.51% (p=0.000 n=9+10) RepeatLarge/134217728/1-16 4.60GB/s ±16% 6.52GB/s ± 9% +41.67% (p=0.000 n=10+10) RepeatLarge/134217728/16-16 4.80GB/s ± 4% 6.81GB/s ± 2% +41.82% (p=0.000 n=10+9) RepeatLarge/134217728/4097-16 4.79GB/s ± 4% 6.81GB/s ± 2% +42.31% (p=0.000 n=9+10) RepeatLarge/268435456/1-16 4.43GB/s ±25% 6.27GB/s ±14% +41.52% (p=0.000 n=10+10) RepeatLarge/268435456/16-16 4.75GB/s ± 4% 6.68GB/s ± 4% +40.50% (p=0.000 n=9+10) RepeatLarge/268435456/4097-16 4.75GB/s ± 3% 6.58GB/s ± 4% +38.68% (p=0.000 n=9+10) RepeatLarge/536870912/1-16 4.96GB/s ± 9% 6.39GB/s ±16% +28.90% (p=0.000 n=8+10) RepeatLarge/536870912/16-16 4.66GB/s ± 6% 6.57GB/s ± 7% +40.82% (p=0.000 n=10+9) RepeatLarge/536870912/4097-16 4.68GB/s ±11% 6.88GB/s ± 3% +47.01% (p=0.000 n=10+9) RepeatLarge/1073741824/1-16 4.39GB/s ±23% 6.57GB/s ± 5% +49.75% (p=0.000 n=10+8) RepeatLarge/1073741824/16-16 4.73GB/s ±13% 6.89GB/s ± 1% +45.68% (p=0.000 n=9+8) RepeatLarge/1073741824/4097-16 4.97GB/s ±15% 6.73GB/s ± 9% +35.45% (p=0.000 n=10+10) The results above come from a Intel i9-9980HK (256KB L2) with TurboBoost disabled. Change-Id: I79dd57da0429aee9020ffd7bc458a034b999b740 Reviewed-on: https://go-review.googlesource.com/c/go/+/419054 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> |
|
|
|
c70fd4b30a |
bytes, strings: add ASCII fast path to EqualFold
This commit adds an ASCII fast path to bytes/strings EqualFold that roughly doubles performance when all characters are ASCII. It also changes strings.EqualFold to use `for range` for the first string since this is ~10% faster than using utf8.DecodeRuneInString for both (see #31666). Performance (similar results on arm64 and amd64): name old time/op new time/op delta EqualFold/Tests-10 238ns ± 0% 172ns ± 1% -27.91% (p=0.000 n=10+10) EqualFold/ASCII-10 20.5ns ± 0% 9.7ns ± 0% -52.73% (p=0.000 n=10+10) EqualFold/UnicodePrefix-10 86.5ns ± 0% 77.6ns ± 0% -10.37% (p=0.000 n=10+10) EqualFold/UnicodeSuffix-10 86.8ns ± 2% 71.3ns ± 0% -17.88% (p=0.000 n=10+8) Change-Id: I058f3f97a08dc04d65af895674d85420f920abe1 Reviewed-on: https://go-review.googlesource.com/c/go/+/425459 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> |
|
|
|
fd82718e06 |
internal/bytealg: correct alignment checks for compare/memequal on riscv64
On riscv64 we need 8 byte alignment for 8 byte loads - the existing check was only ensuring 4 byte alignment, which potentially results in unaligned loads being performed. Unaligned loads incur a significant performance penality due to the resulting kernel traps and fix ups. Adjust BenchmarkCompareBytesBigUnaligned so that this issue would have been more readily visible. Updates #50615 name old time/op new time/op delta CompareBytesBigUnaligned/offset=1-4 6.98ms _ 5% 6.84ms _ 3% ~ (p=0.319 n=5+5) CompareBytesBigUnaligned/offset=2-4 6.75ms _ 1% 6.99ms _ 4% ~ (p=0.063 n=5+5) CompareBytesBigUnaligned/offset=3-4 6.84ms _ 1% 6.74ms _ 1% -1.48% (p=0.003 n=5+5) CompareBytesBigUnaligned/offset=4-4 146ms _ 1% 7ms _ 6% -95.08% (p=0.000 n=5+5) CompareBytesBigUnaligned/offset=5-4 7.05ms _ 5% 6.75ms _ 1% ~ (p=0.079 n=5+5) CompareBytesBigUnaligned/offset=6-4 7.11ms _ 5% 6.89ms _ 5% ~ (p=0.177 n=5+5) CompareBytesBigUnaligned/offset=7-4 7.14ms _ 5% 6.91ms _ 6% ~ (p=0.165 n=5+5) name old speed new speed delta CompareBytesBigUnaligned/offset=1-4 150MB/s _ 5% 153MB/s _ 3% ~ (p=0.336 n=5+5) CompareBytesBigUnaligned/offset=2-4 155MB/s _ 1% 150MB/s _ 4% ~ (p=0.058 n=5+5) CompareBytesBigUnaligned/offset=3-4 153MB/s _ 1% 156MB/s _ 1% +1.51% (p=0.004 n=5+5) CompareBytesBigUnaligned/offset=4-4 7.16MB/s _ 1% 145.79MB/s _ 6% +1936.23% (p=0.000 n=5+5) CompareBytesBigUnaligned/offset=5-4 149MB/s _ 5% 155MB/s _ 1% ~ (p=0.078 n=5+5) CompareBytesBigUnaligned/offset=6-4 148MB/s _ 5% 152MB/s _ 5% ~ (p=0.175 n=5+5) CompareBytesBigUnaligned/offset=7-4 147MB/s _ 5% 152MB/s _ 6% ~ (p=0.160 n=5+5) Change-Id: I2c859e061919db482318ce63b85b808aa973a9ba Reviewed-on: https://go-review.googlesource.com/c/go/+/431099 Reviewed-by: Meng Zhuo <mzh@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> |
|
|
|
2a627afe13 |
bytes: simplify code using unsafe.SliceData
Updates #54854 Change-Id: I9c14f9fa595f73eae44eb714abc5d486915893c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/428155 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> |
|
|
|
70de482d17 |
bytes: rely on utf8.AppendRune
This is both simpler and more performant. WriteRune 23.9µs ± 1% 22.8µs ± 8% -4.43% (p=0.006 n=8+10) ToUpper/longɐstringɐwithɐnonasciiⱯchars 573ns ± 4% 474ns ± 6% -17.27% (p=0.000 n=10+10) ToUpper/ɐɐɐɐɐ 236ns ± 6% 202ns ± 5% -14.12% (p=0.000 n=10+10) ToUpper/a\u0080\U0010ffff 98.8ns ± 6% 91.2ns ± 3% -7.67% (p=0.000 n=10+10) ToLower/LONGⱯSTRINGⱯWITHⱯNONASCIIⱯCHARS 511ns ± 3% 409ns ± 4% -20.02% (p=0.000 n=10+10) ToLower/ⱭⱭⱭⱭⱭ 178ns ± 4% 173ns ± 2% -2.76% (p=0.005 n=10+10) ToLower/A\u0080\U0010ffff 100ns ± 3% 91ns ± 2% -8.55% (p=0.000 n=10+10) Change-Id: I968ef194da2c115cbdcac2d3575c34c65e6a8a56 Reviewed-on: https://go-review.googlesource.com/c/go/+/412337 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> |
|
|
|
5f0170f9a5 |
bytes, strings: s/after/before/ in CutSuffix
This follows on CL 407176 which added this function (in both packages). This CL makes it consistent with the Cut function, which uses “before” and “after” in return variable names. Change-Id: Id4345d2fe0f50bf301a880803e87bf356986b518 Reviewed-on: https://go-review.googlesource.com/c/go/+/424922 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
68005592b3 |
strings, bytes: add CutPrefix and CutSuffix
Fixes #42537 Change-Id: Ie03c2614ffee30ebe707acad6b9f6c28fb134a45 Reviewed-on: https://go-review.googlesource.com/c/go/+/407176 Reviewed-by: Benny Siegert <bsiegert@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Changkun Ou <mail@changkun.de> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
7b45edb450 |
bytes: add Clone function
The new Clone function returns a copy of b[:len(b)] for the input byte slice b. The result may have additional unused capacity. Clone(nil) returns nil. Fixes #45038 Change-Id: I0469a202d77a7b491f1341c08915d07ddd1f0300 Reviewed-on: https://go-review.googlesource.com/c/go/+/359675 Run-TryBot: Martin Möhrmann <martin@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Martin Möhrmann <moehrmann@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> |
|
|
|
9a4685f220 |
strings: avoid utf8.RuneError mangling in Split
Split should only split strings and not perform mangling of invalid UTF-8 into ut8.RuneError. The prior behavior is clearly a bug since mangling is not performed in all other situations (e.g., separator is non-empty). Fixes #53511 Change-Id: I112a2ef15ee46ddecda015ee14bca04cd76adfbf Reviewed-on: https://go-review.googlesource.com/c/go/+/413715 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> |
|
|
|
ceefd3a37b |
bytes: document that Reader.Reset affects the result of Size
The Reader.Reset changes the underlying byte slice, so it actually
changes the return value of the Size method.
Fixes #54018
Change-Id: I160deaa2244e95cb93303cb5dfb67a8d90a375ef
GitHub-Last-Rev:
|
|
|
|
7ca1e2aa56 |
internal/bytealg: optimize index function for ppc64le/power9
Optimized index2to16 loop by unrolling the loop by 4. Multiple benchmark tests show performance improvement on POWER9. Similar improvements are seen on POWER10. Added tests to ensure changes work fine. name old time/op new time/op delta Index/10 18.3ns ± 0% 19.7ns ±25% ~ Index/32 75.3ns ± 0% 69.2ns ± 0% -8.22% Index/4K 5.53µs ± 0% 3.69µs ± 0% -33.20% Index/4M 5.64ms ± 0% 3.75ms ± 0% -33.55% Index/64M 92.9ms ± 0% 61.6ms ± 0% -33.69% IndexHard2 1.41ms ± 0% 0.93ms ± 0% -33.75% CountHard2 1.41ms ± 0% 0.93ms ± 0% -33.75% Change-Id: If9331df6a141a4716724b8cb648d2b91bdf17e5f Reviewed-on: https://go-review.googlesource.com/c/go/+/377016 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Archana Ravindar <aravind5@in.ibm.com> |
|
|
|
5e4543c29f |
bytes: explode checks for n too large
As is already done in strings package.
Change-Id: Ia45e6443ddf6beac5e70a1cc493119030e173139
GitHub-Last-Rev:
|
|
|
|
19309779ac |
all: gofmt main repo
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> |
|
|
|
c451a02a6d |
strings, bytes: improve the description of simple case-folding in EqualFold
This CL removes the problem description pointed out by @bjkail. Second, synchronously modify the comments of the bytes package. Updates #52022 Fixes #52204 Change-Id: I0aa52c774f40bb91f32bebdd2a62a11067a77be0 Reviewed-on: https://go-review.googlesource.com/c/go/+/398736 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Auto-Submit: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Cherry Mui <cherryyz@google.com> |
|
|
|
5bb2628c6f |
bytes: limit allocation in SplitN
So that bytes.SplitN("", "T", int(144115188075855872)) does not panic.
Change-Id: I7c068852bd708416164fc2ed8b84cf6b2d593666
GitHub-Last-Rev:
|
|
|
|
32fdad19a2 |
bytes: restore old Trim/TrimLeft behavior for nil
Keep returning nil for the cases where we historically returned nil, even though this is slightly different for TrimLeft and TrimRight. Fixes #51793 Change-Id: Ifbdfc6b09d52b8e063cfe6341019f9b2eb8b70e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/393876 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> |
|
|
|
2d026a4ea5 |
bytes: rely on runtime.growslice for growing
Rather than naively making a slice of capacity 2*c+n, rely on the append(..., make(...)) pattern to allocate a slice that aligns up to the closest size class. Performance: name old time/op new time/op delta BufferWriteBlock/N4096 3.03µs ± 6% 2.04µs ± 6% -32.60% (p=0.000 n=10+10) BufferWriteBlock/N65536 47.8µs ± 6% 28.1µs ± 2% -41.32% (p=0.000 n=9+8) BufferWriteBlock/N1048576 844µs ± 7% 510µs ± 5% -39.59% (p=0.000 n=8+9) name old alloc/op new alloc/op delta BufferWriteBlock/N4096 12.3kB ± 0% 7.2kB ± 0% -41.67% (p=0.000 n=10+10) BufferWriteBlock/N65536 258kB ± 0% 130kB ± 0% -49.60% (p=0.000 n=10+10) BufferWriteBlock/N1048576 4.19MB ± 0% 2.10MB ± 0% -49.98% (p=0.000 n=10+8) name old allocs/op new allocs/op delta BufferWriteBlock/N4096 3.00 ± 0% 3.00 ± 0% ~ (all equal) BufferWriteBlock/N65536 7.00 ± 0% 7.00 ± 0% ~ (all equal) BufferWriteBlock/N1048576 11.0 ± 0% 11.0 ± 0% ~ (all equal) The performance is faster since the growth rate is capped at 2x, while previously it could grow by amounts potentially much greater than 2x, leading to significant amounts of memory waste and extra copying. Credit goes to Martin Möhrmann for suggesting the append(b, make([]T, n)...) pattern. Fixes #42984 Updates #51462 Change-Id: I7b23f75dddbf53f8b8b93485bb1a1fff9649b96b Reviewed-on: https://go-review.googlesource.com/c/go/+/349994 Trust: Joseph Tsai <joetsai@digital-static.net> Trust: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> |
|
|
|
540632841e |
bytes, strings: mention Cut in docs for Split and SplitN
For #46336 Change-Id: Idc23302085e14e24d571f5995d6d33ca964a0021 Reviewed-on: https://go-review.googlesource.com/c/go/+/382954 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> |
|
|
|
2580d0e08d |
all: gofmt -w -r 'interface{} -> any' src
And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.
Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.
A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.
Fixes #49884.
Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09
Reviewed-on: https://go-review.googlesource.com/c/go/+/368254
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
|
|
7aed6dd7e1 |
strings, bytes: deprecate Title
Title doesn't handle Unicode punctuation and language-specific capitalization rules. Replace the BUG comment with a Deprecated one, suggesting a more robust alternative, and allowing Title to be exposed to tooling. Fixes #48367. Change-Id: I952f1f37cd35b587a95893fb022827bdd9ec7de9 Reviewed-on: https://go-review.googlesource.com/c/go/+/359485 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Cherry Mui <cherryyz@google.com> |
|
|
|
3e9e02412e |
bytes: add example with (*Buffer).Cap, (*Buffer).Read, (*Buffer).ReadByte
Change-Id: Ieb107fdfccde9f054491f667a384b16f7af71dea Reviewed-on: https://go-review.googlesource.com/c/go/+/355289 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Cherry Mui <cherryyz@google.com> |
|
|
|
4e7dd9fc08 |
bytes: test for page boundary crosses on sep of Index
Improve TestIndexNearPageBoundary to verify needles ending on a page boundary don't cause a segfault. Change-Id: I2edb13db63a71dc9955e266f6b97026ee13bf76e Reviewed-on: https://go-review.googlesource.com/c/go/+/356889 Reviewed-by: Cherry Mui <cherryyz@google.com> Trust: Lynn Boger <laboger@linux.vnet.ibm.com> |
|
|
|
a59e33224e |
net/netip: add new IP address package
Co-authored-by: Alex Willmer <alex@moreati.org.uk> (GitHub @moreati) Co-authored-by: Alexander Yastrebov <yastrebov.alex@gmail.com> Co-authored-by: David Anderson <dave@natulte.net> (Tailscale CLA) Co-authored-by: David Crawshaw <crawshaw@tailscale.com> (Tailscale CLA) Co-authored-by: Dmytro Shynkevych <dmytro@tailscale.com> (Tailscale CLA) Co-authored-by: Elias Naur <mail@eliasnaur.com> Co-authored-by: Joe Tsai <joetsai@digital-static.net> (Tailscale CLA) Co-authored-by: Jonathan Yu <jawnsy@cpan.org> (GitHub @jawnsy) Co-authored-by: Josh Bleecher Snyder <josharian@gmail.com> (Tailscale CLA) Co-authored-by: Maisem Ali <maisem@tailscale.com> (Tailscale CLA) Co-authored-by: Manuel Mendez (Go AUTHORS mmendez534@...) Co-authored-by: Matt Layher <mdlayher@gmail.com> Co-authored-by: Noah Treuhaft <noah.treuhaft@gmail.com> (GitHub @nwt) Co-authored-by: Stefan Majer <stefan.majer@gmail.com> Co-authored-by: Terin Stock <terinjokes@gmail.com> (Cloudflare CLA) Co-authored-by: Tobias Klauser <tklauser@distanz.ch> Fixes #46518 Change-Id: I0041f9e1115d61fa6e95fcf32b01d9faee708712 Reviewed-on: https://go-review.googlesource.com/c/go/+/339309 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Trust: Brad Fitzpatrick <bradfitz@golang.org> |
|
|
|
3fa9ee49a0 |
bytes: remove redundant type conversion
Change-Id: Icafb2d9fd11b23d3acaf9df07e7f90d8bcd829fa
GitHub-Last-Rev:
|
|
|
|
f229e7031a |
all: go fix -fix=buildtag std cmd (except for bootstrap deps, vendor)
When these packages are released as part of Go 1.18, Go 1.16 will no longer be supported, so we can remove the +build tags in these files. Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs as defined in src/cmd/dist/buildtool.go, which need to continue to build with Go 1.4 for now. Also reverted src/vendor and src/cmd/vendor, which will need to be updated in their own repos first. Manual changes in runtime/pprof/mprof_test.go to adjust line numbers. For #41184. Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e Reviewed-on: https://go-review.googlesource.com/c/go/+/344955 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> |
|
|
|
3986e5c8e7 |
bytes: fix Cut godoc typo
If sep does not appear in s, we return nil here rather than the empty string. Presumably the docs were copied from the strings package implementation and brought that along. Change-Id: I3706c94fe04abd9e2a2c8840f7cc6116386965c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/354969 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Alexander Rakoczy <alex@golang.org> |
|
|
|
4002616f9a |
strings,bytes: avoid allocations in Trim/TrimLeft/TrimRight
There is evidence that the vast majority of uses for Trim* involve cutsets with a single ASCII character, and the vast majority of remaining uses involve cutsets with a small (<4) ASCII characters. For this reason it makes sense to provide better fast paths for these common cases. Furthermore the current implementation needlessly allocates for unclear benefits. This CL also replaces all paths to avoid allocations and, as a side effect, it speeds up also the slow path. strings: name old time/op new time/op delta Trim 1.71µs ± 1% 0.70µs ± 0% -58.93% (p=0.008 n=5+5) TrimASCII/1:1 6.43ns ± 0% 6.34ns ± 0% -1.41% (p=0.008 n=5+5) TrimASCII/1:2 97.3ns ± 0% 18.2ns ± 1% -81.34% (p=0.008 n=5+5) TrimASCII/1:4 101ns ± 0% 21ns ± 0% -78.77% (p=0.008 n=5+5) TrimASCII/1:8 109ns ± 0% 29ns ± 0% -73.60% (p=0.008 n=5+5) TrimASCII/1:16 124ns ± 0% 43ns ± 0% -65.16% (p=0.008 n=5+5) TrimASCII/16:1 19.8ns ± 0% 18.6ns ± 0% -5.90% (p=0.008 n=5+5) TrimASCII/16:2 167ns ± 0% 33ns ± 0% -80.21% (p=0.008 n=5+5) TrimASCII/16:4 169ns ± 0% 35ns ± 0% -79.01% (p=0.008 n=5+5) TrimASCII/16:8 177ns ± 0% 43ns ± 0% -75.88% (p=0.008 n=5+5) TrimASCII/16:16 193ns ± 2% 57ns ± 1% -70.30% (p=0.008 n=5+5) TrimASCII/256:1 232ns ± 0% 232ns ± 0% ~ (p=1.000 n=5+5) TrimASCII/256:2 1.28µs ± 1% 0.26µs ± 0% -79.46% (p=0.008 n=5+5) TrimASCII/256:4 1.27µs ± 0% 0.27µs ± 0% -78.95% (p=0.008 n=5+5) TrimASCII/256:8 1.28µs ± 0% 0.28µs ± 1% -78.28% (p=0.008 n=5+5) TrimASCII/256:16 1.30µs ± 1% 0.29µs ± 0% -77.49% (p=0.008 n=5+5) TrimASCII/4096:1 3.47µs ± 0% 3.47µs ± 0% -0.14% (p=0.008 n=5+5) TrimASCII/4096:2 18.2µs ± 0% 3.9µs ± 0% -78.53% (p=0.008 n=5+5) TrimASCII/4096:4 18.2µs ± 0% 3.9µs ± 0% -78.55% (p=0.008 n=5+5) TrimASCII/4096:8 18.2µs ± 0% 3.9µs ± 0% -78.49% (p=0.008 n=5+5) TrimASCII/4096:16 18.3µs ± 0% 3.9µs ± 0% -78.44% (p=0.008 n=5+5) TrimByte 10.6ns ± 1% 10.1ns ± 0% -5.01% (p=0.008 n=5+5) TrimSpace/NoTrim 5.90ns ± 0% 5.89ns ± 0% ~ (p=0.135 n=5+5) TrimSpace/ASCII 10.6ns ± 0% 9.9ns ± 0% -6.21% (p=0.008 n=5+5) TrimSpace/SomeNonASCII 127ns ± 0% 126ns ± 0% -0.96% (p=0.008 n=5+5) TrimSpace/JustNonASCII 178ns ± 0% 178ns ± 0% ~ (p=0.825 n=5+4) name old alloc/op new alloc/op delta Trim 456B ± 0% 0B -100.00% (p=0.008 n=5+5) TrimASCII/1:1 0.00B 0.00B ~ (all equal) TrimASCII/1:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:1 0.00B 0.00B ~ (all equal) TrimASCII/16:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:1 0.00B 0.00B ~ (all equal) TrimASCII/256:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:1 0.00B 0.00B ~ (all equal) TrimASCII/4096:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:16 48.0B ± 0% 0.0B ~ (p=0.079 n=4+5) TrimByte 0.00B 0.00B ~ (all equal) TrimSpace/NoTrim 0.00B 0.00B ~ (all equal) TrimSpace/ASCII 0.00B 0.00B ~ (all equal) TrimSpace/SomeNonASCII 0.00B 0.00B ~ (all equal) TrimSpace/JustNonASCII 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta Trim 18.0 ± 0% 0.0 -100.00% (p=0.008 n=5+5) TrimASCII/1:1 0.00 0.00 ~ (all equal) TrimASCII/1:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:1 0.00 0.00 ~ (all equal) TrimASCII/16:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:1 0.00 0.00 ~ (all equal) TrimASCII/256:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:1 0.00 0.00 ~ (all equal) TrimASCII/4096:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimByte 0.00 0.00 ~ (all equal) TrimSpace/NoTrim 0.00 0.00 ~ (all equal) TrimSpace/ASCII 0.00 0.00 ~ (all equal) TrimSpace/SomeNonASCII 0.00 0.00 ~ (all equal) TrimSpace/JustNonASCII 0.00 0.00 ~ (all equal) bytes: name old time/op new time/op delta TrimSpace/NoTrim 5.89ns ± 0% 5.91ns ± 0% ~ (p=0.095 n=5+4) TrimSpace/ASCII 10.3ns ± 1% 10.2ns ± 0% ~ (p=0.095 n=5+5) TrimSpace/SomeNonASCII 120ns ± 1% 121ns ± 0% +1.13% (p=0.008 n=5+5) TrimSpace/JustNonASCII 194ns ± 1% 195ns ± 0% ~ (p=0.143 n=5+5) TrimASCII/1:1 6.28ns ± 0% 5.95ns ± 0% -5.26% (p=0.008 n=5+5) TrimASCII/1:2 95.8ns ± 1% 18.6ns ± 0% -80.63% (p=0.008 n=5+5) TrimASCII/1:4 98.8ns ± 0% 22.1ns ± 0% -77.62% (p=0.008 n=5+5) TrimASCII/1:8 107ns ± 0% 29ns ± 0% -72.72% (p=0.008 n=5+5) TrimASCII/1:16 123ns ± 0% 44ns ± 1% -64.30% (p=0.008 n=5+5) TrimASCII/16:1 13.2ns ± 0% 12.8ns ± 1% -2.75% (p=0.008 n=5+5) TrimASCII/16:2 169ns ± 0% 33ns ± 0% -80.33% (p=0.008 n=5+5) TrimASCII/16:4 173ns ± 0% 36ns ± 0% -79.31% (p=0.008 n=5+5) TrimASCII/16:8 180ns ± 0% 43ns ± 0% -76.02% (p=0.008 n=5+5) TrimASCII/16:16 197ns ± 2% 58ns ± 0% -70.73% (p=0.008 n=5+5) TrimASCII/256:1 137ns ± 1% 136ns ± 0% -0.82% (p=0.016 n=5+5) TrimASCII/256:2 1.40µs ± 0% 0.26µs ± 0% -81.02% (p=0.008 n=5+5) TrimASCII/256:4 1.40µs ± 0% 0.27µs ± 0% -80.83% (p=0.008 n=5+5) TrimASCII/256:8 1.41µs ± 0% 0.28µs ± 0% -80.36% (p=0.008 n=5+5) TrimASCII/256:16 1.42µs ± 0% 0.29µs ± 0% -79.48% (p=0.008 n=5+5) TrimASCII/4096:1 1.75µs ± 0% 1.75µs ± 0% ~ (p=0.595 n=5+5) TrimASCII/4096:2 20.9µs ± 0% 3.9µs ± 0% -81.29% (p=0.008 n=5+5) TrimASCII/4096:4 20.9µs ± 0% 3.9µs ± 0% -81.27% (p=0.008 n=5+5) TrimASCII/4096:8 20.9µs ± 0% 3.9µs ± 0% -81.22% (p=0.008 n=5+5) TrimASCII/4096:16 20.9µs ± 0% 3.9µs ± 0% -81.21% (p=0.008 n=5+5) TrimByte 9.21ns ± 0% 9.30ns ± 0% +0.91% (p=0.008 n=5+5) name old alloc/op new alloc/op delta TrimSpace/NoTrim 0.00B 0.00B ~ (all equal) TrimSpace/ASCII 0.00B 0.00B ~ (all equal) TrimSpace/SomeNonASCII 0.00B 0.00B ~ (all equal) TrimSpace/JustNonASCII 0.00B 0.00B ~ (all equal) TrimASCII/1:1 0.00B 0.00B ~ (all equal) TrimASCII/1:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/1:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:1 0.00B 0.00B ~ (all equal) TrimASCII/16:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/16:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:1 0.00B 0.00B ~ (all equal) TrimASCII/256:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/256:16 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:1 0.00B 0.00B ~ (all equal) TrimASCII/4096:2 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:4 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:8 48.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimASCII/4096:16 49.0B ± 0% 0.0B -100.00% (p=0.008 n=5+5) TrimByte 0.00B 0.00B ~ (all equal) name old allocs/op new allocs/op delta TrimSpace/NoTrim 0.00 0.00 ~ (all equal) TrimSpace/ASCII 0.00 0.00 ~ (all equal) TrimSpace/SomeNonASCII 0.00 0.00 ~ (all equal) TrimSpace/JustNonASCII 0.00 0.00 ~ (all equal) TrimASCII/1:1 0.00 0.00 ~ (all equal) TrimASCII/1:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/1:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:1 0.00 0.00 ~ (all equal) TrimASCII/16:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/16:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:1 0.00 0.00 ~ (all equal) TrimASCII/256:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/256:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:1 0.00 0.00 ~ (all equal) TrimASCII/4096:2 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:8 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimASCII/4096:16 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5) TrimByte 0.00 0.00 ~ (all equal) Fixes #46446 Change-Id: I9537c86f888af6285027f67bda4a97aeedb41d4a Reviewed-on: https://go-review.googlesource.com/c/go/+/332771 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Joe Tsai <joetsai@digital-static.net> Trust: Joe Tsai <joetsai@digital-static.net> Trust: Than McIntosh <thanm@google.com> |
|
|
|
8e36ab0551 |
bytes, strings: add Cut
Using Cut is a clearer way to write the vast majority (>70%) of existing code that calls Index, IndexByte, IndexRune, and SplitN. There is more discussion on https://golang.org/issue/46336. Fixes #46336. Change-Id: Ia418ed7c3706c65bf61e1b2c5baf534cb783e4d3 Reviewed-on: https://go-review.googlesource.com/c/go/+/351710 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> |
|
|
|
078247a407 |
bytes: add example for (*Buffer).Next
Change-Id: Ic0a97fd7bb89865448e436e5c092415a29d8badf Reviewed-on: https://go-review.googlesource.com/c/go/+/352009 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: David Chase <drchase@google.com> |
|
|
|
5baf60d472 |
bytes, strings: optimize Trim for single byte cutsets
Using the latest version of all modules known by the module proxy, we determine that for all Trim usages (and related functionality): * 76.6% have cutsets of len=1, and * 13.4% have cutsets of len=2. Given that a vast majority of usages only have a cutset of len=1, we should more heavily optimize for that situation. Previously, there was some optimization for cutsets of len=1, but it's within the internal makeCutsetFunc function. This is sub-optimal as it incurs an allocation in makeCutsetFunc for the closure over that single byte. This CL removes special-casing of one-byte cutsets from makeCutsetFunc and instead distributes it directly in Trim, TrimRight, and TrimLeft. Whether we should distribute the entire ASCII cutset logic into Trim is a future CL that should be discussed and handled separately. The evidence for multibyte cutsets is not as obviously compelling. name old time/op new time/op delta bytes/TrimByte-4 84.1ns ± 2% 7.5ns ± 1% -91.10% (p=0.000 n=9+7) strings/TrimByte-4 86.2ns ± 3% 8.3ns ± 1% -90.33% (p=0.000 n=9+10) Fixes #46446 Change-Id: Ia0e31a8384c3ce111ae35465605bcec45df2ebec Reviewed-on: https://go-review.googlesource.com/c/go/+/323318 Trust: Joe Tsai <joetsai@digital-static.net> Run-TryBot: Joe Tsai <joetsai@digital-static.net> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Go Bot <gobot@golang.org> |
|
|
|
8ac6544564 |
bytes: correct tense in comment
Undo incorrect change accidentally made in CL 299109. Change-Id: Iba29827d0fbd3637c311cebc50c2f4ea437fc582 Reviewed-on: https://go-review.googlesource.com/c/go/+/301830 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> |
|
|
|
289d34a465 |
all: remove duplicate words
Change-Id: Ib0469232a2b69a869e58d5d24990ad74ac96ea56
GitHub-Last-Rev:
|
|
|
|
43652dc46f |
bufio, bytes, strings: handle negative runes in WriteRune
Updates #43254 Change-Id: I7d4bf3b99cc36ca2156af5bb01a1c595419d1d3c Reviewed-on: https://go-review.googlesource.com/c/go/+/280492 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Rob Pike <r@golang.org> Trust: Emmanuel Odeke <emmanuel@orijtech.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Go Bot <gobot@golang.org> |