A follow-up for the recent https://go.dev/cl/573978.
Change-Id: I0e75ca0b37d9ef063bbdfb88d4d2e34647e0ee50
Reviewed-on: https://go-review.googlesource.com/c/go/+/574677
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This is a follow-up to CL 574675.
Change-Id: I98c3ea968e9c7dc61472849c385a1e697568aa30
Reviewed-on: https://go-review.googlesource.com/c/go/+/574975
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Jes Cok <xigua67damn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The documentation of ServeFileFS was partly copied from ServeFile
in CL 513956, however it's not exact. This CL fixes some typos, also
removes obsolete comment for name param.
For consistency, also adds godoc link for ServeFile and ServeContent.
Fixes#66578
Change-Id: I87147d72c533d46284f06ef20b37fdafa8706710
Reviewed-on: https://go-review.googlesource.com/c/go/+/575016
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Change-Id: I1290ad66d3c758c3b89caf0a217cb3d5358c5dd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/574696
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This new logic more closely mimics what we did before my CL stack.
I had reasoned that certainly
ts.adjust(now, force=true)
ts.run(now)
would be faster than
ts.adjust(now, force=false)
ts.run(now)
ts.adjust(now, force=true)
But certainty is just an emotion, and that turns out not to be the case.
I don't really understand why the second sequence is faster,
but it definitely is, so put it back.
goos: linux
goarch: amd64
pkg: time
cpu: AMD Ryzen 9 7950X 16-Core Processor
│ s7base.txt │ s7.txt │
│ sec/op │ sec/op vs base │
AdjustTimers10000-32 263.3µ ± 4% 239.9µ ± 5% -8.87% (p=0.000 n=10)
AdjustTimers10000SingleThread-32 1.742m ± 3% 1.686m ± 8% ~ (p=0.105 n=10)
AdjustTimers10000NoReset-32 192.2µ ± 2% 194.1µ ± 1% +1.00% (p=0.009 n=10)
AdjustTimers10000NoSleep-32 237.0µ ± 2% 226.2µ ± 3% -4.55% (p=0.001 n=10)
AdjustTimers10000NoResetNoSleep-32 185.2µ ± 1% 182.9µ ± 1% -1.23% (p=0.003 n=10)
goos: darwin
goarch: arm64
pkg: time
cpu: Apple M3 Pro
│ m3base.txt │ m3.txt │
│ sec/op │ sec/op vs base │
AdjustTimers10000-12 272.6µ ± 3% 269.3µ ± 2% ~ (p=0.063 n=10)
AdjustTimers10000SingleThread-12 1.126m ± 1% 1.176m ± 1% +4.42% (p=0.000 n=10)
AdjustTimers10000NoReset-12 255.1µ ± 2% 262.6µ ± 2% +2.96% (p=0.000 n=10)
AdjustTimers10000NoSleep-12 250.2µ ± 2% 247.8µ ± 1% ~ (p=0.063 n=10)
AdjustTimers10000NoResetNoSleep-12 230.3µ ± 1% 231.0µ ± 1% ~ (p=0.280 n=10)
Change-Id: I67b5765f97dfca0142ee38e15a9904b520f51e83
Reviewed-on: https://go-review.googlesource.com/c/go/+/574740
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The new code does not need a for-loop and is easier to read.
Change-Id: Ic182d63c4779c2179b721fcfaec362681284cc16
GitHub-Last-Rev: b3ee265df7
GitHub-Pull-Request: golang/go#63879
Reviewed-on: https://go-review.googlesource.com/c/go/+/538721
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
sysctl machdep.cpu.brand_string seems to be standard
across the BSDs. There does not seem to be a standard
way to get the CPU frequency.
Change-Id: Ic986d6c81dd54e1b84544317f2a53ce16801319b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520636
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
All of these maps and slices are made up of comparable types,
so we can avoid the overhead of reflection entirely.
Change-Id: If77dbe648a336ba729c171e84c9ff3f7e160297d
Reviewed-on: https://go-review.googlesource.com/c/go/+/574597
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This helps reduce confusion with cmd/internal/pgo, which performs
compilation-independent analysis. pgoir associates that data with the
IR from the current package compilation.
For #58102.
Change-Id: I9ef1c8bc41db466d3340f41f6d071b95c09566de
Reviewed-on: https://go-review.googlesource.com/c/go/+/569338
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The processing performed in cmd/preprofile is a simple version of the
same initial processing performed by cmd/compile/internal/pgo. Refactor
this processing into the new IR-independent cmd/internal/pgo package.
Now cmd/preprofile and cmd/compile run the same code for initial
processing of a pprof profile, guaranteeing that they always stay in
sync.
Since it is now trivial, this CL makes one change to the serialization
format: the entries are ordered by weight. This allows us to avoid
sorting ByWeight on deserialization.
Impact on PGO parsing when compiling cmd/compile with PGO:
* Without preprocessing: PGO parsing ~13.7% of CPU time
* With preprocessing (unsorted): ~2.9% of CPU time (sorting ~1.7%)
* With preprocessing (sorted): ~1.3% of CPU time
The remaining 1.3% of CPU time approximately breaks down as:
* ~0.5% parsing the preprocessed profile
* ~0.7% building weighted IR call graph
* ~0.5% walking function IR to find direct calls
* ~0.2% performing lookups for indirect calls targets
For #58102.
Change-Id: Iaba425ea30b063ca195fb2f7b29342961c8a64c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/569337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Windows, File.readdir currently fails if the volume information
can't be retrieved via GetVolumeInformationByHandle and if the
directory path is relative and can't be converted to an absolute
path.
This change makes readdir more robust by not failing in these cases,
as these steps are just necessary to support a potential call to
os.SameFile, but not for the actual readdir operation. os.SameFile
will still fail in these cases, but that's a separate issue tracked
in #62042.
Change-Id: I8d98d8379bdac4b2832fa433432a5f027756abaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/574155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For https://gcc.gnu.org/PR114453
Change-Id: If41d9fca6288b18ed47b0f21ff224c74ddb34958
Reviewed-on: https://go-review.googlesource.com/c/go/+/574536
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I1df0685c75fc1044ba46003a69ecc7dfc53bbc2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/574675
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This check serves only to provide a more descriptive error if the output
directory doesn't exist. That isn't useless, but I don't see why this tool
specifically should do this when no other part of the toolchain does.
For #58102.
Change-Id: I01cf9db2cc1dad85c3afd8a6b008c53f26cb877a
Reviewed-on: https://go-review.googlesource.com/c/go/+/569336
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adjusts error handling to be a bit more idiomatic. The
processing function returns errors, leaving main to log and exit on
error.
This CL contains no functional changes.
For #58102.
Change-Id: I9074127cc675e177d046474b7f01fbc37d0bd4c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/569335
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In setupRSA we use named returns so that we can defer freeing of the
boring private key and context, but were using returns of the form
`return nil, nil, ...` which nil'd the named returns, preventing them
from actually being freed.
Update all of the returns to not shadow the named variables.
Thanks to Quim Muntal of Microsoft for reporting this issue.
Change-Id: Iaf0f0b17e123a7df730cb1e91a324fe622611f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/574195
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Might help with OOMs on 32-bit platforms
Change-Id: Idd5129c61ecdfeedd5a9a18fce85dbba27cab946
Reviewed-on: https://go-review.googlesource.com/c/go/+/574475
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 561080 introduced some failures for CBC and GCM crypto tests that are run during a build resulting in dashboard failures.
Tests that are failing:
- TestCBCEncrypterAES
- TestCBCDecrypterAES
- TestAESGCM
- TestGCMCounterWrap
- TestGCMAsm
This fixes those failures.
Change-Id: I90d6f8d279a3051cf951a1a9628afb8d0b5c2f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/574076
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Partial typo corrections, following https://go.dev/wiki/Spelling
Change-Id: I2357906ff2ea04305c6357418e4e9556e20375d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/573776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Use the slices package and the built-in max to simplify the code.
There's no noticeable performance change in this modification.
Change-Id: I96e46ba8ab1323f1ba0b8c9b827836e217772cf2
GitHub-Last-Rev: f0111ac7e2
GitHub-Pull-Request: golang/go#66511
Reviewed-on: https://go-review.googlesource.com/c/go/+/573978
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Use a list + sorting instead of a map to keep track of collisions.
Should save a fair amount of memory.
Change-Id: I7b48cdb5f7060d12ebbb950d56b5c479f131c027
Reviewed-on: https://go-review.googlesource.com/c/go/+/574275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Keith Randall <khr@google.com>
For Clone, Grow, Clip, Concat, Contains, Repeat.
Fixes#66435
Change-Id: Ife8f61427e9cd18b7106c100de8f82f9d7840c9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/573255
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Callers who invoke `*http.Client.Do` with a nil *Client will now panic
at the top of c.Do, instead of panicking when `deadline` attempts to
read `c.Timeout`.
Errors inside of net/http can be difficult to track down because the
caller is often invoking the standard library code via an SDK. This
can mean that there are many places to check when code panics, and
raises the importance of being clear about error messages.
If nil receiver calls panic during the `deadline()` call, callers
may confuse the error with a more common timeout or deadline
misconfiguration, which may lead a caller who passed a nil receiver
(the author, for example) down the wrong rabbit hole, or cause them to
suspect their timeout/deadline logic. It is less common to configure
client.Jar, so the probability of detecting the actual problem, given
the underlying error cause, is higher.
Fixes#53521.
Change-Id: If102d17bed56fdd950da6e87762166fd29724654
Reviewed-on: https://go-review.googlesource.com/c/go/+/413975
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Windows syscall.SyscallN currently calls lockOSThread for every syscall.
This can be expensive and produce unnecessary context switches,
especially when the syscall is called frequently under high contention.
The lockOSThread was necessary to ensure that cgocall wouldn't
reschedule the goroutine to a different M, as the syscall return values
are reported back in the M struct.
This CL instructs cgocall to copy the syscall return values into the
the M that will see the caller on return, so the caller no longer needs
to call lockOSThread.
Updates #58336.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64,gotip-windows-amd64-longtest
Change-Id: If6644fd111dbacab74e7dcee2afa18ca146735da
Reviewed-on: https://go-review.googlesource.com/c/go/+/562915
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Follow up CL 560155
Change-Id: Id9230d79c296452f3741123c75b45c3d3b1be4f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/574295
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There was recently a failure that we don't have a trace dump for because
the reader was passed Go122 but traces have moved onto version Go123.
Use version.Current to prevent this from happening again in the future.
Change-Id: I4f8b3c3ea5bad61a07839a697cd5d7793d62ea52
Reviewed-on: https://go-review.googlesource.com/c/go/+/574216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
base.ExitIfErrors() has been deferred at the begin of the function,
no need to call it again.
Change-Id: I4fc81572cfce0f84832448da667c65bb477dea22
GitHub-Last-Rev: cc15635875
GitHub-Pull-Request: golang/go#66392
Reviewed-on: https://go-review.googlesource.com/c/go/+/572576
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Replace some "reflect.DeepEqual" calls in the tests with
"slices.Equal" which is much faster for slice comparisons.
Remove unnecessary "runeSlice" and redundant helper functions.
Change-Id: Ib5dc41848d7a3c5149f41701d60471a487cff476
GitHub-Last-Rev: 87b5ed043d
GitHub-Pull-Request: golang/go#66509
Reviewed-on: https://go-review.googlesource.com/c/go/+/573977
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I0f67801ef2d3af65c39a27b8db6ebaa769ff7f92
GitHub-Last-Rev: feb7f79ea5
GitHub-Pull-Request: golang/go#66508
Reviewed-on: https://go-review.googlesource.com/c/go/+/574075
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We can reuse the buffer pool more aggressively when reading a directory
by returning the buffer to the pool as soon as we get to the end of the
directory, rather than waiting until the the os.File is closed.
This yields a significant memory usage reduction when traversing
nested directories recursively via os.File#ReadDir (and friends),
as the file pointers tends to be closed only after the entire
traversal is done. For example, this pattern is used in os.RemoveAll.
These are the improvements observed in BenchmarkRemoveAll:
goos: linux
goarch: amd64
pkg: os
cpu: AMD EPYC 7763 64-Core Processor
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
RemoveAll-4 3.847m ± 2% 3.823m ± 1% ~ (p=0.143 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
RemoveAll-4 39.77Ki ± 2% 17.63Ki ± 1% -55.68% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
RemoveAll-4 510.0 ± 0% 503.0 ± 0% -1.37% (p=0.000 n=10)
Change-Id: I70e1037378a02f1d670ccb7b275ee55f0caa6d0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/573358
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
We log TLS handshake errors in general, but currently do not log errors
when the first TLS record looks like an attempt to send HTTP to an HTTPS
port. There doesn't seem to be any principled reason to log the one and
not the other, so just log all TLS handshake errors.
Fixes#66501
Change-Id: I5d78a754d054c220be935513448515721fa387a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/573979
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Plain string concatenation with the plus operator for Attr.String is
much faster than invoking fmt.Sprintf. Added a benchmark to verify
this (just running on my Mac with stuff in the background but should
be sufficient to demonstrate the effect).
name old time/op new time/op delta
AttrString-8 1.24µs ± 3% 0.43µs ± 0% -65.17% (p=0.000 n=20+17)
name old alloc/op new alloc/op delta
AttrString-8 432B ± 0% 152B ± 0% ~ (p=1.000 n=1+1)
name old allocs/op new allocs/op delta
AttrString-8 30.0 ± 0% 16.0 ± 0% ~ (p=1.000 n=1+1)
Change-Id: I18ac91cbff1047d168b51a595601e36b5f676615
Reviewed-on: https://go-review.googlesource.com/c/go/+/573517
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Keep ReadTimeout, ReadHeaderTimeout, IdleTimeout and WriteTimeout in sync
Change-Id: I32b43884c0078eca86f20ec363f1d702ba298d1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/573315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
