| Age | Commit message (Collapse) | Author |
|---|
|
Add linknames for most modules with ≥50 dependents.
Add linknames for a few other modules that we know
are important but are below 50.
Remove linknames from badlinkname.go that do not merit
inclusion (very small number of dependents).
We can add them back later if the need arises.
Fixes #67401. (For now.)
Change-Id: I1e49fec0292265256044d64b1841d366c4106002
Reviewed-on: https://go-review.googlesource.com/c/go/+/587756
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Doing this because the slices functions are slightly faster and
slightly easier to use. It also removes one dependency layer.
This CL does not change packages that are used during bootstrap,
as the bootstrap compiler does not have the required slices functions.
It does not change the go/scanner package because the ErrorList
Len, Swap, and Less methods are part of the Go 1 API.
Change-Id: If52899be791c829198e11d2408727720b91ebe8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/587655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
The Repeat("-", maxInt) call should produce
panic: runtime error: makeslice: len out of range
instead of
panic: strings: Repeat output length overflow
This PR is only for theory perfection.
Change-Id: If67d87b147d666fbbb7238656f2a0cb6cf1dbb5b
GitHub-Last-Rev: 29dc0cb9c9c63d8a008960b4527d6aa6798c1c17
GitHub-Pull-Request: golang/go#67068
Reviewed-on: https://go-review.googlesource.com/c/go/+/581936
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
|
[Reader.Reader] does not exist in this package.
These docs most likely meant to refer to [Reader] itself.
Change-Id: I4fa117e8541573e0be7c13751fdfc102d5f2d604
Reviewed-on: https://go-review.googlesource.com/c/go/+/582515
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>
|
|
TestNewBufferShallow should be skipped if optimization is disabled.
It is currently failing on no-opt builders.
Change-Id: Ib5e62022a56a4e5f158f247d69a6229d2cb4d99e
Reviewed-on: https://go-review.googlesource.com/c/go/+/581915
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joedian Reid <joedian@google.com>
|
|
At present, there is no API to reset the underlying []byte
of an existing Buffer struct, except to shallow copy
the entire Buffer struct.
Updates #67004
Change-Id: I08998f7a95ae5bde0897d86247d47f23cd784583
Reviewed-on: https://go-review.googlesource.com/c/go/+/581297
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Joedian Reid <joedian@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
correctly
The document address currently showing the problem is: https://pkg.go.dev/bytes#Buffer.ReadByte
Change-Id: Ib52747e38f72541f3ca2a595aa8eca5d91281c80
Reviewed-on: https://go-review.googlesource.com/c/go/+/568135
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
|
|
Fixes #64833
Change-Id: Ice3f5dfab65f5525bc7a6f57ddeaabda8d64dfa3
GitHub-Last-Rev: 38f1d6c19d8ec29ae5645ce677839a301f798df3
GitHub-Pull-Request: golang/go#64835
Reviewed-on: https://go-review.googlesource.com/c/go/+/552135
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
If memequal is invoked with the same pointers as arguments it ends up
comparing the whole memory contents, instead of just comparing the pointers.
This effectively makes an operation that could be O(1) into O(n). All the
other architectures already have this optimization in place. For
instance, arm64 also have it, in memequal_varlen.
Such optimization is very specific, one case that it will probably benefit is
programs that rely heavily on interning of strings.
goos: darwin
goarch: arm64
pkg: bytes
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Equal/same/1-8 2.678n ± ∞ ¹ 2.400n ± ∞ ¹ -10.38% (p=0.008 n=5)
Equal/same/6-8 3.267n ± ∞ ¹ 2.431n ± ∞ ¹ -25.59% (p=0.008 n=5)
Equal/same/9-8 2.981n ± ∞ ¹ 2.385n ± ∞ ¹ -19.99% (p=0.008 n=5)
Equal/same/15-8 2.974n ± ∞ ¹ 2.390n ± ∞ ¹ -19.64% (p=0.008 n=5)
Equal/same/16-8 2.983n ± ∞ ¹ 2.380n ± ∞ ¹ -20.21% (p=0.008 n=5)
Equal/same/20-8 3.567n ± ∞ ¹ 2.384n ± ∞ ¹ -33.17% (p=0.008 n=5)
Equal/same/32-8 3.568n ± ∞ ¹ 2.385n ± ∞ ¹ -33.16% (p=0.008 n=5)
Equal/same/4K-8 78.040n ± ∞ ¹ 2.378n ± ∞ ¹ -96.95% (p=0.008 n=5)
Equal/same/4M-8 78713.000n ± ∞ ¹ 2.385n ± ∞ ¹ -100.00% (p=0.008 n=5)
Equal/same/64M-8 1348095.000n ± ∞ ¹ 2.381n ± ∞ ¹ -100.00% (p=0.008 n=5)
geomean 43.52n 2.390n -94.51%
¹ need >= 6 samples for confidence interval at level 0.95
│ old.txt │ new.txt │
│ B/s │ B/s vs base │
Equal/same/1-8 356.1Mi ± ∞ ¹ 397.3Mi ± ∞ ¹ +11.57% (p=0.008 n=5)
Equal/same/6-8 1.711Gi ± ∞ ¹ 2.298Gi ± ∞ ¹ +34.35% (p=0.008 n=5)
Equal/same/9-8 2.812Gi ± ∞ ¹ 3.515Gi ± ∞ ¹ +24.99% (p=0.008 n=5)
Equal/same/15-8 4.698Gi ± ∞ ¹ 5.844Gi ± ∞ ¹ +24.41% (p=0.008 n=5)
Equal/same/16-8 4.995Gi ± ∞ ¹ 6.260Gi ± ∞ ¹ +25.34% (p=0.008 n=5)
Equal/same/20-8 5.222Gi ± ∞ ¹ 7.814Gi ± ∞ ¹ +49.63% (p=0.008 n=5)
Equal/same/32-8 8.353Gi ± ∞ ¹ 12.496Gi ± ∞ ¹ +49.59% (p=0.008 n=5)
Equal/same/4K-8 48.88Gi ± ∞ ¹ 1603.96Gi ± ∞ ¹ +3181.17% (p=0.008 n=5)
Equal/same/4M-8 49.63Gi ± ∞ ¹ 1637911.85Gi ± ∞ ¹ +3300381.91% (p=0.008 n=5)
Equal/same/64M-8 46.36Gi ± ∞ ¹ 26253069.97Gi ± ∞ ¹ +56626517.99% (p=0.008 n=5)
geomean 6.737Gi 122.7Gi +1721.01%
¹ need >= 6 samples for confidence interval at level 0.95
Fixes #64381
Change-Id: I7d423930a688edd88c4ba60d45e097296d9be852
GitHub-Last-Rev: ae8189fafb1cba87b5394f09f971746ae9299273
GitHub-Pull-Request: golang/go#64419
Reviewed-on: https://go-review.googlesource.com/c/go/+/545416
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
This bottoms out in internal/bytealg.Count, which does a fair amount
of avx shenanigans. Make sure we're not reading out of bounds.
Change-Id: Ied0e461f536f75acc24c6797f7fc74e3f3901c10
Reviewed-on: https://go-review.googlesource.com/c/go/+/533116
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Also rename 'substr' to 'sep' in IndexRabinKarp for consistency.
Change-Id: Icc2ad1116aecaf002c8264daa2fa608306c9a88a
GitHub-Last-Rev: 1784b93f53d569991f86585f9011120ea26f193f
GitHub-Pull-Request: golang/go#63854
Reviewed-on: https://go-review.googlesource.com/c/go/+/538716
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
This is a follow-up to CL 538175.
Change-Id: Iec2523b36a16d7e157c17858c89fcd43c2470d58
GitHub-Last-Rev: 812d36e57c71ea3bf44d2d64bde0703ef02a1b91
GitHub-Pull-Request: golang/go#63770
Reviewed-on: https://go-review.googlesource.com/c/go/+/538195
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
|
|
…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: b11a2bf9476d54bed4bd18a3f9269b5c95a66d67
GitHub-Pull-Request: golang/go#63766
Reviewed-on: https://go-review.googlesource.com/c/go/+/538175
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ic93ad59119f3549c0f13c4f366f71e9d01b88c47
GitHub-Last-Rev: afb518047288976f440d3fe0d65923c1905a9b26
GitHub-Pull-Request: golang/go#57907
Reviewed-on: https://go-review.googlesource.com/c/go/+/462283
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
Change-Id: I63181f6540fc1bfcfc988a16bf9fafbd3575cfdf
GitHub-Last-Rev: d90528730a92a087866c1bfc227a0a0bf1cdffbe
GitHub-Pull-Request: golang/go#57909
Reviewed-on: https://go-review.googlesource.com/c/go/+/462284
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: b04724a072d956db1f84a8f5db0afa0dbb158e96
GitHub-Pull-Request: golang/go#54020
Reviewed-on: https://go-review.googlesource.com/c/go/+/419237
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
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>
|
|
As is already done in strings package.
Change-Id: Ia45e6443ddf6beac5e70a1cc493119030e173139
GitHub-Last-Rev: 1174c250350f31eced1513169d62a8a3e679dcf6
GitHub-Pull-Request: golang/go#52348
Reviewed-on: https://go-review.googlesource.com/c/go/+/400239
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
[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>
|
|
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>
|
|
So that bytes.SplitN("", "T", int(144115188075855872)) does not panic.
Change-Id: I7c068852bd708416164fc2ed8b84cf6b2d593666
GitHub-Last-Rev: f8df09d65e2bc889fbd0c736bfb5e9a9078dfced
GitHub-Pull-Request: golang/go#52147
Reviewed-on: https://go-review.googlesource.com/c/go/+/398076
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: mzh <mzh@golangcn.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
