| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I6a23219a9e05350bdd9205e19165d5944f15de31
GitHub-Last-Rev: 8c295bf55feaa07cd487e6015029c4682a1480b0
GitHub-Pull-Request: golang/go#69429
Reviewed-on: https://go-review.googlesource.com/c/go/+/612719
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
|
Fixes #66249
Change-Id: I5973a19a087a35ad951e8a220d3e6e4456c7577f
GitHub-Last-Rev: 921ca8bd0c08687bb727dbfb0890c3355eebe95b
GitHub-Pull-Request: golang/go#66599
Reviewed-on: https://go-review.googlesource.com/c/go/+/575295
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
|
|
The OID type is not exported data like most of the other x509 structs.
Using it in x509.Certificate made Certificate not gob-compatible anymore,
which breaks real-world code. As a temporary fix, make gob ignore
that field, making it work as well as it did in Go 1.21.
For Go 1.23, we anticipate adding a proper fix and removing the gob
workaround. See #65633 and #66249 for more details.
For #66249.
Fixes #65633.
Change-Id: Idd1431d15063b3009e15d0565cd3120b9fa13f61
Reviewed-on: https://go-review.googlesource.com/c/go/+/571095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
Across all encoding packages, linkify declarations if possible.
In some cases, we convert a code block into a bulleted list,
which then further allows for more linkification.
Change-Id: I68fedf362615b34228bab5d4859b7d87d831c570
Reviewed-on: https://go-review.googlesource.com/c/go/+/524977
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: I80c494a357195dad3ade98fcce0a6883303777ce
GitHub-Last-Rev: a30615f3733fb0a43628cc81df7ad286e789b445
GitHub-Pull-Request: golang/go#62422
Reviewed-on: https://go-review.googlesource.com/c/go/+/524998
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
I believe this bug is introduced by CL 460543 which optimizes the allocations
by changing the type of `idToType` from map to slice, but didn't update the
access code in `Decoder.typeString` that is safe for map but not for slice.
Fixes #62117
Change-Id: I0f2e4cc2f34c54dada1f83458ba512a6fde6dcbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/520757
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
|
|
This avoids several mildly confusing Elem calls.
For #60088
Change-Id: If7b83d2ab10537c7e886a035b43cb272130c1669
Reviewed-on: https://go-review.googlesource.com/c/go/+/514455
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Rob Pike <r@golang.org>
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>
|
|
fieldType is a struct with only a string and an integer,
so its size will barely be three times that of a pointer.
The indirection doesn't save us any memory or append/grow cost,
but it does cause a significant amount of allocations at init time.
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 730.9n ± 5% 741.6n ± 5% ~ (p=0.529 n=10)
EncodingGob 173.7µ ± 0% 171.1µ ± 0% -1.46% (p=0.000 n=10)
geomean 11.27µ 11.26µ -0.01%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.27Ki ± 0% 34.30Ki ± 0% -10.38% (p=0.000 n=10)
geomean 8.221Ki 7.782Ki -5.33%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 642.0 ± 0% 615.0 ± 0% -4.21% (p=0.000 n=10)
geomean 35.83 35.07 -2.13%
¹ all samples are equal
Change-Id: I852a799834d2e9b7b915da74e871a4052d13892e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479400
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
After the previous commit, both calls use the non-pointer type,
so we can deduplicate. No noticeable difference in init cost.
Change-Id: I0f0fb91d42655787cb58b4442ad3da4194560af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/479399
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
wireType itself is just a struct with seven pointer fields,
so an indirection doesn't feel necessary to noticeably reduce the amount
of memory that typeInfo takes for each Go type registered in gob.
The indirection does add a small amount of overhead though,
particularly one extra allocation when registering a type,
which is done a number of times as part of init.
For consistency, also update wireTypeUserInfo to not use a pointer.
Measuring via one of the end-to-end benchmarks and benchinit:
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 736.8n ± 5% 733.9n ± 5% ~ (p=0.971 n=10)
EncodingGob 177.6µ ± 0% 173.6µ ± 0% -2.27% (p=0.000 n=10)
geomean 11.44µ 11.29µ -1.34%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.47Ki ± 0% 38.27Ki ± 0% -0.50% (p=0.000 n=10)
geomean 8.241Ki 8.220Ki -0.25%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 652.0 ± 0% 642.0 ± 0% -1.53% (p=0.000 n=10)
geomean 36.11 35.83 -0.77%
¹ all samples are equal
Change-Id: I528080b7d990ed595683f155a1ae25dcd26394b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/479398
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Doing this work at init time does make the first encode or decode call
slightly faster, but the cost is still paid upfront.
However, not all programs which directly or indirectly import
encoding/gob end up encoding or decoding any values.
For example, a program might only be run with the -help flag,
or it might only use gob encoding when a specific mode is enabled.
Moreover, any work done at init time needs to happen sequentially and
before the main function can start, blocking the entire program.
Using benchinit, we see a moderate saving at init time:
goos: linux
goarch: amd64
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EncodingGob 188.9µ ± 0% 175.4µ ± 0% -7.15% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
EncodingGob 39.78Ki ± 0% 38.46Ki ± 0% -3.32% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
EncodingGob 668.0 ± 0% 652.0 ± 0% -2.40% (p=0.000 n=10)
Change-Id: I75a5df18c9b1d02566e5885a966360d8a525913a
Reviewed-on: https://go-review.googlesource.com/c/go/+/479396
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
|
|
https://go.dev/cl/460543 stopped using the "expect" parameter in
bootstrapType, but we forgot to actually remove it.
While here, staticcheck correctly points out that we can use the copy
builtin to fill builtinIdToTypeSlice, now that it and idToType are an
array and slice respectively.
Change-Id: I48078415ab9bdd5633cf41f33ab4dc78eb30b48a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462301
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Avoid unnecessary allocations when calling reflect.TypeOf;
we can use nil pointers, which fit into an interface without allocating.
This saves about 1% of CPU time.
The builtin types are limited to typeIds between 0 and firstUserId,
and since firstUserId is 64, builtinIdToType does not need to be a map.
We can simply use an array of length firstUserId, which is simpler.
This saves about 1% of CPU time.
idToType is similar to firstUserId in that it is a map keyed by typeIds.
The difference is that it can grow with the user's types.
However, each added type gets the next available typeId,
meaning that we can use a growing slice, similar to the case above.
nextId then becomes the current length of the slice.
This saves about 1% of CPU time.
typeInfoMap is stored globally as an atomic.Value,
where each modification loads the map, makes a whole copy,
adds the new element, and stores the modified copy.
This is perfectly fine when the user registers types,
as that can happen concurrently and at any point in the future.
However, during init time, we sequentially register many types,
and the overhead of copying maps adds up noticeably.
During init time, use a regular global map instead,
which gets replaced by the atomic.Value when our init work is done.
This saves about 2% of CPU time.
Finally, avoid calling checkId in bootstrapType;
we have just called setTypeId, whose logic for getting nextId is simple,
so the extra check doesn't gain us much.
This saves about 1% of CPU time.
Using benchinit, which transforms GODEBUG=inittrace=1 data into Go
benchmark compatible output, results in a nice improvement:
name old time/op new time/op delta
EncodingGob 175µs ± 0% 162µs ± 0% -7.45% (p=0.016 n=5+4)
name old alloc/op new alloc/op delta
EncodingGob 39.0kB ± 0% 36.1kB ± 0% -7.35% (p=0.016 n=5+4)
name old allocs/op new allocs/op delta
EncodingGob 588 ± 0% 558 ± 0% -5.10% (p=0.000 n=5+4)
Updates #26775.
Change-Id: I28618e8b96ef440480e666ef2cd5c4a9a332ef21
Reviewed-on: https://go-review.googlesource.com/c/go/+/460543
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: I17a311afb94a056b3d35bfa241f5d0d206db602d
GitHub-Last-Rev: 42129464c9e17fae9b61ea60940e193fcefc5760
GitHub-Pull-Request: golang/go#55962
Reviewed-on: https://go-review.googlesource.com/c/go/+/436882
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Replace loading and storing an atomic.Value of type pointer with
atomic.Pointer.
Change-Id: I018ac1e18eee4f203ebca65c2833daf991075371
Reviewed-on: https://go-review.googlesource.com/c/go/+/422174
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Rob Pike <r@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>
|
|
Updates #47651
Updates #48665
Change-Id: I69a87b45a5cad7a07fbd855040cd9935cf874554
Reviewed-on: https://go-review.googlesource.com/c/go/+/358454
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This provides a significant speedup for encoding and decoding when
using many CPU cores.
name old time/op new time/op delta
EndToEndPipe 5.26µs ± 2% 5.38µs ± 7% ~ (p=0.121 n=8+7)
EndToEndPipe-6 1.86µs ± 5% 1.80µs ±11% ~ (p=0.442 n=8+8)
EndToEndPipe-48 1.39µs ± 2% 1.41µs ± 4% ~ (p=0.645 n=8+8)
EndToEndByteBuffer 1.54µs ± 5% 1.57µs ± 5% ~ (p=0.130 n=8+8)
EndToEndByteBuffer-6 620ns ± 6% 310ns ± 8% -50.04% (p=0.000 n=8+8)
EndToEndByteBuffer-48 506ns ± 4% 110ns ± 3% -78.22% (p=0.000 n=8+8)
EndToEndSliceByteBuffer 149µs ± 3% 153µs ± 5% +2.80% (p=0.021 n=8+8)
EndToEndSliceByteBuffer-6 103µs ±17% 31µs ±12% -70.06% (p=0.000 n=8+8)
EndToEndSliceByteBuffer-48 93.2µs ± 2% 18.0µs ± 5% -80.66% (p=0.000 n=7+8)
EncodeComplex128Slice 20.6µs ± 5% 20.9µs ± 8% ~ (p=0.959 n=8+8)
EncodeComplex128Slice-6 4.10µs ±10% 3.75µs ± 8% -8.58% (p=0.004 n=8+7)
EncodeComplex128Slice-48 1.14µs ± 2% 0.81µs ± 2% -28.98% (p=0.000 n=8+8)
EncodeFloat64Slice 10.2µs ± 7% 10.1µs ± 6% ~ (p=0.694 n=7+8)
EncodeFloat64Slice-6 2.01µs ± 6% 1.80µs ±11% -10.30% (p=0.004 n=8+8)
EncodeFloat64Slice-48 701ns ± 3% 408ns ± 2% -41.72% (p=0.000 n=8+8)
EncodeInt32Slice 11.8µs ± 7% 11.7µs ± 6% ~ (p=0.463 n=8+7)
EncodeInt32Slice-6 2.32µs ± 4% 2.06µs ± 5% -10.89% (p=0.000 n=8+8)
EncodeInt32Slice-48 731ns ± 2% 445ns ± 2% -39.10% (p=0.000 n=7+8)
EncodeStringSlice 9.13µs ± 9% 9.18µs ± 8% ~ (p=0.798 n=8+8)
EncodeStringSlice-6 1.91µs ± 5% 1.70µs ± 5% -11.07% (p=0.000 n=8+8)
EncodeStringSlice-48 679ns ± 3% 397ns ± 3% -41.50% (p=0.000 n=8+8)
EncodeInterfaceSlice 449µs ±11% 461µs ± 9% ~ (p=0.328 n=8+8)
EncodeInterfaceSlice-6 503µs ± 7% 88µs ± 7% -82.51% (p=0.000 n=7+8)
EncodeInterfaceSlice-48 335µs ± 8% 22µs ± 1% -93.55% (p=0.000 n=8+7)
DecodeComplex128Slice 67.2µs ± 4% 67.0µs ± 6% ~ (p=0.721 n=8+8)
DecodeComplex128Slice-6 22.0µs ± 8% 18.9µs ± 5% -14.44% (p=0.000 n=8+8)
DecodeComplex128Slice-48 46.8µs ± 3% 34.9µs ± 3% -25.48% (p=0.000 n=8+8)
DecodeFloat64Slice 39.4µs ± 4% 40.3µs ± 3% ~ (p=0.105 n=8+8)
DecodeFloat64Slice-6 16.1µs ± 2% 11.2µs ± 7% -30.64% (p=0.001 n=6+7)
DecodeFloat64Slice-48 38.1µs ± 3% 24.0µs ± 7% -37.10% (p=0.000 n=8+8)
DecodeInt32Slice 39.1µs ± 4% 40.1µs ± 5% ~ (p=0.083 n=8+8)
DecodeInt32Slice-6 16.3µs ±21% 10.6µs ± 1% -35.17% (p=0.000 n=8+7)
DecodeInt32Slice-48 36.5µs ± 6% 21.9µs ± 9% -39.89% (p=0.000 n=8+8)
DecodeStringSlice 82.9µs ± 6% 85.5µs ± 5% ~ (p=0.121 n=8+7)
DecodeStringSlice-6 32.4µs ±11% 26.8µs ±16% -17.37% (p=0.000 n=8+8)
DecodeStringSlice-48 76.0µs ± 2% 57.0µs ± 5% -25.02% (p=0.000 n=8+8)
DecodeInterfaceSlice 718µs ± 4% 752µs ± 5% +4.83% (p=0.038 n=8+8)
DecodeInterfaceSlice-6 500µs ± 6% 165µs ± 7% -66.95% (p=0.000 n=7+8)
DecodeInterfaceSlice-48 470µs ± 5% 120µs ± 6% -74.55% (p=0.000 n=8+7)
DecodeMap 3.29ms ± 5% 3.34ms ± 5% ~ (p=0.279 n=8+8)
DecodeMap-6 7.73ms ± 8% 7.53ms ±18% ~ (p=0.779 n=7+8)
DecodeMap-48 7.46ms ± 6% 7.71ms ± 3% ~ (p=0.161 n=8+8)
https://perf.golang.org/search?q=upload:20170426.4
Change-Id: I335874028ef8d7c991051004f8caadd16c92d5cc
Reviewed-on: https://go-review.googlesource.com/41872
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I6a882d9f0bc20b7a8bf73765e055d9344f3f401f
Reviewed-on: https://go-review.googlesource.com/15422
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Replace typeLock with copy-on-write map using atomic.Value.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 7722 7709 -0.17%
BenchmarkEndToEndPipe-2 5114 4344 -15.06%
BenchmarkEndToEndPipe-4 3192 2429 -23.90%
BenchmarkEndToEndPipe-8 1833 1438 -21.55%
BenchmarkEndToEndPipe-16 1332 983 -26.20%
BenchmarkEndToEndPipe-32 1444 675 -53.25%
BenchmarkEndToEndByteBuffer 6474 6019 -7.03%
BenchmarkEndToEndByteBuffer-2 4280 2810 -34.35%
BenchmarkEndToEndByteBuffer-4 2264 1774 -21.64%
BenchmarkEndToEndByteBuffer-8 1275 979 -23.22%
BenchmarkEndToEndByteBuffer-16 1257 753 -40.10%
BenchmarkEndToEndByteBuffer-32 1342 644 -52.01%
BenchmarkEndToEndArrayByteBuffer 727725 671349 -7.75%
BenchmarkEndToEndArrayByteBuffer-2 394079 320473 -18.68%
BenchmarkEndToEndArrayByteBuffer-4 211785 178175 -15.87%
BenchmarkEndToEndArrayByteBuffer-8 141003 118857 -15.71%
BenchmarkEndToEndArrayByteBuffer-16 139249 86367 -37.98%
BenchmarkEndToEndArrayByteBuffer-32 144128 73454 -49.04%
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/147720043
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|
