- 07 Mar, 2017 2 commits
-
-
Michael Munday authored
Should fix the build dashboard. Change-Id: Id4c8a996d9f689e1fa865a9cff9a7f52c700c691 Reviewed-on: https://go-review.googlesource.com/37877 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Jaana Burcu Dogan authored
Change-Id: I4718c82540ef214728393824b89c8c7f6656823b Reviewed-on: https://go-review.googlesource.com/36210Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 06 Mar, 2017 32 commits
-
-
Robert Griesemer authored
This reverts commit cb6e0639. The fix is incorrect as it's perfectly fine to refer to an identifier 'init' inside a function, and 'init' may even be a variable of function value. Misspelling 'init' in that context would lead to an incorrect error message. Reopened #8481. Change-Id: I49787fdf7738213370ae6f0cab54013e9e3394a8 Reviewed-on: https://go-review.googlesource.com/37876 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
philhofer authored
Given (Store [c] (OffPtr <T1> [0] (Addr <T> _)) _ (Store [c] (Addr <T> _) _ _)) dead store elimination doesn't eliminate the inner Store, because it addresses a type of a different width than the first store. When decomposing StructMake operations, always generate an OffPtr to address struct fields so that dead stores to the first field of the struct can be optimized away. benchmarks affected on darwin/amd64: HTTPClientServer-8 73.2µs ± 1% 72.7µs ± 1% -0.69% (p=0.022 n=9+10) TimeParse-8 304ns ± 1% 300ns ± 0% -1.61% (p=0.000 n=9+9) RegexpMatchEasy1_32-8 80.1ns ± 0% 79.5ns ± 1% -0.84% (p=0.000 n=8+9) GobDecode-8 6.78ms ± 0% 6.81ms ± 1% +0.46% (p=0.000 n=9+10) Gunzip-8 36.1ms ± 1% 36.2ms ± 0% +0.37% (p=0.019 n=10+10) JSONEncode-8 15.6ms ± 0% 15.7ms ± 0% +0.69% (p=0.000 n=9+10) Change-Id: Ia80d73fd047f9400c616ca64fdee4f438a0e7f21 Reviewed-on: https://go-review.googlesource.com/37769 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Keith Randall <khr@golang.org>
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I66f5a191cf9c9a11a7c3c4d7ee0a02e2c185f019 Reviewed-on: https://go-review.googlesource.com/37841Reviewed-by:
-
Robert Griesemer authored
Debugging support. Change-Id: Ia518aaed36eaba76e6233306f718ad8aff3ce744 Reviewed-on: https://go-review.googlesource.com/37875Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I402383e893223facae451adbd640113126d5edd9 Reviewed-on: https://go-review.googlesource.com/37873 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Shrinks LSym somewhat for non-STEXT LSyms, which are much more common. While here, switch to tracking Automs in a slice instead of a linked list. (Previously, this would have made LSyms larger.) Passes toolstash-check. Change-Id: I082e50e1d1f1b544c9e06b6e412a186be6a4a2b5 Reviewed-on: https://go-review.googlesource.com/37872Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Matthew Dempsky authored
Instead, cmd/compile can directly emit R_USEFIELD relocations. Manually verified rsc.io/tmp/fieldtrack still passes. Change-Id: Ib1fb5ab902ff0ad17ef6a862a9a5692caf7f87d1 Reviewed-on: https://go-review.googlesource.com/37871 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
By clearing out t.nod in copytype, we effectively lose the reference from a Type back to its declaring OTYPE Node. This means later in typenamesym when we add typenod(t) to signatlist, we end up creating a new OTYPE Node. Moreover, this Node's position information will depend on whatever context it happens be needed, and will be used for the Type's position in the export data. Updates #19391. Change-Id: Ied93126449f75d7c5e3275cbdcc6fa657a8aa21d Reviewed-on: https://go-review.googlesource.com/37870 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Quentin Smith authored
Change-Id: Ie52dac8eb4daed95e049ad74d5ae101e8a5cb854 Reviewed-on: https://go-review.googlesource.com/37725 Run-TryBot: Quentin Smith <quentin@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Austin Clements authored
For historical reasons, it's still commonplace to iterate over the slice returned by runtime.Callers and call FuncForPC on each PC. This is broken in gccgo and somewhat broken in gc and will become more broken in gc with mid-stack inlining. In Go 1.7, we introduced runtime.CallersFrames to deal with these problems, but didn't strongly direct people toward using it. Reword the documentation on runtime.Callers to more strongly encourage people to use CallersFrames and explicitly discourage them from iterating over the PCs or using FuncForPC on the results. Fixes #19426. Change-Id: Id0d14cb51a0e9521c8fdde9612610f2c2b9383c4 Reviewed-on: https://go-review.googlesource.com/37726Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
We're passed a pkg, so it makes little sense to not use it. This was probably a typo and not the intended behaviour. Fixes #19407. Change-Id: Ia1c9130c0e474daf47753cf51914a2d7db272c96 Reviewed-on: https://go-review.googlesource.com/37839Reviewed-by:
-
Ian Lance Taylor authored
We don't need to start the goroutines if the program isn't going to do any I/O. Fixes #19390. Change-Id: I47eef992d3ad05ed5f3150f4d6e5b3e0cb16a551 Reviewed-on: https://go-review.googlesource.com/37762 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
Josselin Costanzi authored
Fix Decode to return the correct illegal data index from a corrupted input that contains whitespaces. Fixes #19406 Change-Id: Ib2b2b6ed7e41f024d0da2bd035caec4317c2869c Reviewed-on: https://go-review.googlesource.com/37837Reviewed-by:
-
Austin Clements authored
Currently almost every function that deals with a *_func has to first look up the *moduledata for the module containing the function's entry point. This means we almost always do at least two identical module lookups whenever we deal with a *_func (one to get the *_func and another to get something from its module data) and sometimes several more. Fix this by making findfunc return a new funcInfo type that embeds *_func, but also includes the *moduledata, and making all of the functions that currently take a *_func instead take a funcInfo and use the already-found *moduledata. This transformation is trivial for the most part, since the *_func type is usually inferred. The annoying part is that we can no longer use nil to indicate failure, so this introduces a funcInfo.valid() method and replaces nil checks with calls to valid. Change-Id: I9b8075ef1c31185c1943596d96dec45c7ab5100f Reviewed-on: https://go-review.googlesource.com/37331 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Matthew Dempsky authored
Updates the disassembler to support the same object file version used by the assembler and linker. Related #14782. Change-Id: I4cd7560c4e4e1350cfb27ca9cbe0fde25fe693cc Reviewed-on: https://go-review.googlesource.com/37797 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Matthew Dempsky authored
golang.org/cl/37231 changed the object file format, but forgot to bump the version string. Change-Id: I8351ec8ed55e65479006e7c0df20254d0e31015f Reviewed-on: https://go-review.googlesource.com/37798 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I186d2afd067e97eb05d65c4599119b347f82867d Reviewed-on: https://go-review.googlesource.com/37840Reviewed-by:
-
Robert Griesemer authored
For #16088. Change-Id: Ib38bda06a5c5d110ca86510043775c5cf229e6a8 Reviewed-on: https://go-review.googlesource.com/37756Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
For #16088. Change-Id: I0ff480e95ef5af375be2ccc655f8b233a7bcd39d Reviewed-on: https://go-review.googlesource.com/37755Reviewed-by:
-
Robert Griesemer authored
This will make type-checking more robust in the presence of import errors. Also: - import is now relative to directory containing teh file containing the import (matters for relative imports) - factored out package import code from main resolver loop - fixed a couple of minor bugs Fixes #16088. Change-Id: I1ace45c13cd0fa675d1762877cec0a30afd9ecdc Reviewed-on: https://go-review.googlesource.com/37697 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
Austin Clements authored
Currently we acquire a global lock for every newMarkBits call. This is unfortunate since every span sweep operation calls newMarkBits. However, most allocations are simply linear allocations from the current arena. Take advantage of this to add a lock-free fast path for allocating from the current arena. With this change, the global lock only protects the lists of arenas, not the free offset in the current arena. Change-Id: I6cf6182af8492c8bfc21276114c77275fe3d7826 Reviewed-on: https://go-review.googlesource.com/34595 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently, newArena holds the gcBitsArenas lock across allocating memory from the OS for a new gcBits arena. This is a global lock and allocating physical memory can be expensive, so this has the potential to cause high lock contention, especially since every single span sweep operation calls newArena (via newMarkBits). Improve the situation by temporarily dropping the lock across allocation. This means the caller now has to revalidate its assumptions after the lock is dropped, so this also factors out that code path and reinvokes it after the lock is acquired. Change-Id: I1113200a954ab4aad16b5071512583cfac744bdc Reviewed-on: https://go-review.googlesource.com/34594 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Josh Bleecher Snyder authored
We generate a lot of pointless dead blocks during the AST to SSA conversion. There are a few commonly occurring kinds of statements that contain neither variables nor code and that switch to a new block themselves. Stop making dead blocks for them. For the code in #19379, this reduces compilation wall time by 36% and max rss by 28%. This also helps a little for regular code, particularly code heavy on switch statements. name old time/op new time/op delta Template 231ms ± 3% 230ms ± 5% ~ (p=0.402 n=17+16) Unicode 101ms ± 4% 103ms ± 5% ~ (p=0.221 n=19+18) GoTypes 635ms ± 5% 625ms ± 4% ~ (p=0.063 n=20+18) Compiler 2.93s ± 2% 2.89s ± 2% -1.22% (p=0.003 n=20+19) SSA 4.53s ± 3% 4.52s ± 3% ~ (p=0.380 n=20+19) Flate 132ms ± 4% 133ms ± 5% ~ (p=0.647 n=20+19) GoParser 161ms ± 3% 161ms ± 4% ~ (p=0.749 n=20+19) Reflect 403ms ± 4% 397ms ± 3% -1.53% (p=0.030 n=20+19) Tar 121ms ± 2% 121ms ± 8% ~ (p=0.544 n=19+19) XML 225ms ± 3% 224ms ± 4% ~ (p=0.396 n=20+19) name old user-ns/op new user-ns/op delta Template 302user-ms ± 1% 297user-ms ± 7% -1.49% (p=0.048 n=15+18) Unicode 142user-ms ± 3% 143user-ms ± 5% ~ (p=0.363 n=19+17) GoTypes 852user-ms ± 5% 851user-ms ± 3% ~ (p=0.851 n=20+18) Compiler 4.11user-s ± 6% 3.98user-s ± 3% -3.08% (p=0.000 n=20+19) SSA 6.91user-s ± 5% 6.82user-s ± 7% ~ (p=0.113 n=20+19) Flate 164user-ms ± 4% 168user-ms ± 4% +2.42% (p=0.001 n=18+19) GoParser 207user-ms ± 4% 206user-ms ± 4% ~ (p=0.176 n=20+18) Reflect 509user-ms ± 4% 505user-ms ± 4% ~ (p=0.113 n=20+19) Tar 153user-ms ± 7% 151user-ms ± 9% ~ (p=0.283 n=20+19) XML 284user-ms ± 4% 282user-ms ± 4% ~ (p=0.270 n=20+19) name old alloc/op new alloc/op delta Template 42.6MB ± 0% 41.9MB ± 0% -1.55% (p=0.000 n=19+19) Unicode 31.7MB ± 0% 31.7MB ± 0% ~ (p=0.828 n=20+18) GoTypes 124MB ± 0% 121MB ± 0% -2.11% (p=0.000 n=20+17) Compiler 534MB ± 0% 523MB ± 0% -2.06% (p=0.000 n=20+19) SSA 989MB ± 0% 977MB ± 0% -1.28% (p=0.000 n=20+19) Flate 27.8MB ± 0% 27.5MB ± 0% -0.98% (p=0.000 n=20+19) GoParser 34.3MB ± 0% 34.0MB ± 0% -0.81% (p=0.000 n=20+19) Reflect 84.6MB ± 0% 82.9MB ± 0% -2.00% (p=0.000 n=17+18) Tar 28.8MB ± 0% 28.3MB ± 0% -1.52% (p=0.000 n=16+18) XML 47.2MB ± 0% 45.8MB ± 0% -2.99% (p=0.000 n=20+19) name old allocs/op new allocs/op delta Template 421k ± 1% 419k ± 1% -0.41% (p=0.001 n=20+19) Unicode 338k ± 1% 338k ± 1% ~ (p=0.478 n=20+19) GoTypes 1.28M ± 0% 1.28M ± 0% -0.36% (p=0.000 n=20+18) Compiler 5.06M ± 0% 5.03M ± 0% -0.63% (p=0.000 n=20+19) SSA 9.14M ± 0% 9.11M ± 0% -0.34% (p=0.000 n=20+19) Flate 267k ± 1% 266k ± 1% ~ (p=0.149 n=20+19) GoParser 347k ± 0% 347k ± 1% ~ (p=0.103 n=19+19) Reflect 1.07M ± 0% 1.07M ± 0% -0.42% (p=0.000 n=16+18) Tar 274k ± 0% 273k ± 1% ~ (p=0.116 n=19+19) XML 449k ± 0% 446k ± 1% -0.60% (p=0.000 n=20+19) Updates #19379 Change-Id: Ie798c347a0c081f5e349e1529880bebaae290967 Reviewed-on: https://go-review.googlesource.com/37760Reviewed-by:
David Chase <drchase@google.com>
-
Aliaksandr Valialkin authored
This makes Sym flags consistent with the rest of the code after the CL 37445. No functional changes. Passes toolstash -cmp. Change-Id: Ica919f2ab98581371c717fff9a70aeb11058ca17 Reviewed-on: https://go-review.googlesource.com/37847Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: Ic97f05a2ecb5b17caa36aafe403e2266abea3e0e Reviewed-on: https://go-review.googlesource.com/37836 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
On overloaded machines once we get to big N, the machine slowness dominates. But we only retry once we get to a big N. Instead, retry for small N too, and die on the first big N that fails. Change-Id: I3ab9cfb88832ad86e2ba1389a926045091268aeb Reviewed-on: https://go-review.googlesource.com/37543 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
Found via github.com/mvdan/unparam. Change-Id: I12cb0c35b14c880425c347fb3eb146712a86f310 Reviewed-on: https://go-review.googlesource.com/37834Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I5b0c7cfdc1ab4fe0d79ef4c5a31612bbcf2ff3ad Reviewed-on: https://go-review.googlesource.com/37833Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: Ie26e963176eb7afb35d16fed5cbca6530f7731c3 Reviewed-on: https://go-review.googlesource.com/37832Reviewed-by:
-
Eitan Adler authored
Change-Id: I6343c162e27e2e492547c96f1fc504909b1c03c0 Reviewed-on: https://go-review.googlesource.com/37793Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Change-Id: I5a6664cceeba1cf1c2f3236ddf4db5ce7a64b02a Reviewed-on: https://go-review.googlesource.com/37835Reviewed-by:
-
Daniel Martí authored
Found by github.com/mvdan/unparam. Small performance win when the utf8.RuneLen call is removed. name old time/op new time/op delta AppendQuoteRune-4 21.7ns ± 0% 21.4ns ± 0% -1.38% (p=0.008 n=5+5) Change-Id: Ieb3b3e1148db7a3d854c81555a491edeff549f43 Reviewed-on: https://go-review.googlesource.com/37831Reviewed-by:
-
- 05 Mar, 2017 2 commits
-
-
Cherry Zhang authored
The assembler back end uses F15 as a temporary register in these instructions. Checked the assembler back end and made sure that this is the only case clobbering F15. Fixes #19403. Change-Id: I02b9e00fdd9229db899f501c8e9b306e02912d83 Reviewed-on: https://go-review.googlesource.com/37792 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I666d2c6ea8d0b54a71260809d1a2573b122865b2 Reviewed-on: https://go-review.googlesource.com/37790 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 04 Mar, 2017 4 commits
-
-
Josh Bleecher Snyder authored
CL 37234 introduced string concatenation into some hot code. This CL does that work earlier and caches the result. Updates #19386 Performance impact vs master: name old time/op new time/op delta Template 223ms ± 5% 216ms ± 5% -2.98% (p=0.001 n=20+20) Unicode 98.7ms ± 4% 99.0ms ± 4% ~ (p=0.749 n=20+19) GoTypes 631ms ± 4% 626ms ± 4% ~ (p=0.253 n=20+20) Compiler 2.91s ± 1% 2.87s ± 3% -1.11% (p=0.005 n=18+20) SSA 4.48s ± 2% 4.36s ± 2% -2.77% (p=0.000 n=20+20) Flate 130ms ± 2% 129ms ± 6% ~ (p=0.428 n=19+20) GoParser 160ms ± 4% 157ms ± 3% -1.62% (p=0.005 n=20+18) Reflect 395ms ± 2% 394ms ± 4% ~ (p=0.445 n=20+20) Tar 120ms ± 5% 118ms ± 6% ~ (p=0.101 n=19+20) XML 224ms ± 3% 223ms ± 3% ~ (p=0.544 n=19+19) name old user-ns/op new user-ns/op delta Template 291user-ms ± 5% 265user-ms ± 5% -9.02% (p=0.000 n=20+19) Unicode 140user-ms ± 3% 139user-ms ± 8% ~ (p=0.904 n=20+20) GoTypes 844user-ms ± 3% 849user-ms ± 3% ~ (p=0.251 n=20+18) Compiler 4.06user-s ± 5% 3.98user-s ± 2% ~ (p=0.056 n=20+20) SSA 6.89user-s ± 5% 6.50user-s ± 3% -5.61% (p=0.000 n=20+20) Flate 164user-ms ± 5% 163user-ms ± 4% ~ (p=0.365 n=20+19) GoParser 206user-ms ± 6% 204user-ms ± 4% ~ (p=0.534 n=20+18) Reflect 501user-ms ± 4% 505user-ms ± 5% ~ (p=0.383 n=20+20) Tar 151user-ms ± 3% 152user-ms ± 7% ~ (p=0.798 n=17+20) XML 283user-ms ± 7% 280user-ms ± 5% ~ (p=0.301 n=20+20) name old alloc/op new alloc/op delta Template 42.5MB ± 0% 40.2MB ± 0% -5.59% (p=0.000 n=20+20) Unicode 31.7MB ± 0% 31.0MB ± 0% -2.19% (p=0.000 n=20+18) GoTypes 124MB ± 0% 117MB ± 0% -5.90% (p=0.000 n=20+20) Compiler 533MB ± 0% 490MB ± 0% -8.07% (p=0.000 n=20+20) SSA 989MB ± 0% 893MB ± 0% -9.74% (p=0.000 n=20+20) Flate 27.8MB ± 0% 26.1MB ± 0% -5.92% (p=0.000 n=20+20) GoParser 34.3MB ± 0% 32.1MB ± 0% -6.43% (p=0.000 n=19+20) Reflect 84.6MB ± 0% 81.4MB ± 0% -3.84% (p=0.000 n=20+20) Tar 28.8MB ± 0% 27.7MB ± 0% -3.89% (p=0.000 n=20+20) XML 47.2MB ± 0% 44.2MB ± 0% -6.45% (p=0.000 n=20+19) name old allocs/op new allocs/op delta Template 420k ± 1% 381k ± 1% -9.35% (p=0.000 n=20+20) Unicode 338k ± 1% 324k ± 1% -4.29% (p=0.000 n=20+19) GoTypes 1.28M ± 0% 1.15M ± 0% -10.30% (p=0.000 n=20+20) Compiler 5.06M ± 0% 4.41M ± 0% -12.92% (p=0.000 n=20+20) SSA 9.14M ± 0% 7.91M ± 0% -13.46% (p=0.000 n=19+20) Flate 267k ± 0% 241k ± 1% -9.53% (p=0.000 n=20+20) GoParser 347k ± 1% 312k ± 0% -10.15% (p=0.000 n=19+20) Reflect 1.07M ± 0% 1.00M ± 0% -6.86% (p=0.000 n=20+20) Tar 274k ± 1% 256k ± 1% -6.73% (p=0.000 n=20+20) XML 448k ± 0% 398k ± 0% -11.17% (p=0.000 n=20+18) Performance impact when applied together with CL 37234 atop CL 37234's parent commit (i.e. as if it were a part of CL 37234), to show that this commit makes CL 37234 completely performance-neutral: name old time/op new time/op delta Template 222ms ±14% 222ms ±14% ~ (p=1.000 n=14+15) Unicode 104ms ±18% 106ms ±18% ~ (p=0.650 n=13+14) GoTypes 653ms ± 7% 638ms ± 5% ~ (p=0.145 n=14+12) Compiler 3.10s ± 1% 3.13s ±10% ~ (p=1.000 n=2+2) SSA 4.73s ±11% 4.68s ±11% ~ (p=0.567 n=15+15) Flate 136ms ± 4% 133ms ± 7% ~ (p=0.231 n=12+14) GoParser 163ms ±11% 169ms ±10% ~ (p=0.352 n=14+14) Reflect 415ms ±15% 423ms ±20% ~ (p=0.715 n=15+14) Tar 133ms ±17% 130ms ±23% ~ (p=0.252 n=14+15) XML 236ms ±16% 235ms ±14% ~ (p=0.874 n=14+14) name old user-ns/op new user-ns/op delta Template 271user-ms ±10% 271user-ms ±10% ~ (p=0.780 n=14+15) Unicode 143user-ms ± 5% 146user-ms ±11% ~ (p=0.432 n=12+14) GoTypes 864user-ms ± 5% 866user-ms ± 9% ~ (p=0.905 n=14+13) Compiler 4.17user-s ± 1% 4.26user-s ± 7% ~ (p=1.000 n=2+2) SSA 6.79user-s ± 8% 6.79user-s ± 6% ~ (p=0.902 n=15+15) Flate 169user-ms ± 8% 164user-ms ± 5% -3.13% (p=0.014 n=14+14) GoParser 212user-ms ± 7% 217user-ms ±22% ~ (p=1.000 n=13+15) Reflect 521user-ms ± 7% 533user-ms ±15% ~ (p=0.511 n=14+14) Tar 165user-ms ±17% 161user-ms ±15% ~ (p=0.345 n=15+15) XML 294user-ms ±11% 292user-ms ±10% ~ (p=0.839 n=14+14) name old alloc/op new alloc/op delta Template 39.9MB ± 0% 39.9MB ± 0% ~ (p=0.621 n=15+14) Unicode 31.0MB ± 0% 31.0MB ± 0% ~ (p=0.098 n=13+15) GoTypes 117MB ± 0% 117MB ± 0% ~ (p=0.775 n=15+15) Compiler 488MB ± 0% 488MB ± 0% ~ (p=0.333 n=2+2) SSA 892MB ± 0% 892MB ± 0% +0.03% (p=0.000 n=15+15) Flate 26.1MB ± 0% 26.1MB ± 0% ~ (p=0.098 n=15+15) GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.525 n=15+13) Reflect 81.2MB ± 0% 81.2MB ± 0% +0.06% (p=0.001 n=12+14) Tar 27.5MB ± 0% 27.5MB ± 0% ~ (p=0.595 n=15+15) XML 44.1MB ± 0% 44.1MB ± 0% ~ (p=0.486 n=15+15) name old allocs/op new allocs/op delta Template 378k ± 1% 378k ± 0% ~ (p=0.949 n=15+14) Unicode 324k ± 0% 324k ± 1% ~ (p=0.057 n=14+15) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.461 n=15+15) Compiler 4.39M ± 0% 4.39M ± 0% ~ (p=0.333 n=2+2) SSA 7.90M ± 0% 7.90M ± 0% +0.06% (p=0.008 n=15+15) Flate 240k ± 1% 241k ± 0% ~ (p=0.233 n=15+15) GoParser 309k ± 1% 309k ± 0% ~ (p=0.867 n=15+12) Reflect 1.00M ± 0% 1.00M ± 0% ~ (p=0.139 n=12+15) Tar 254k ± 1% 253k ± 1% ~ (p=0.345 n=15+15) XML 398k ± 0% 397k ± 1% ~ (p=0.267 n=15+15) Change-Id: Ic999a0f456a371c99eebba0f9747263a13836e33 Reviewed-on: https://go-review.googlesource.com/37766 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Kevin Burke authored
If you cross compile for a Unix target and call user.Lookup("root") or user.LookupId("0"), we'll try to read the answer out of /etc/passwd instead of returning an "unimplemented" error. The equivalent cgo function calls getpwuid_r in glibc, which may reach out to the NSS database or allow callers to register extensions. The pure Go implementation only reads from /etc/passwd. Change-Id: I56a302d634b15ba5097f9f0d6a758c68e486ba6d Reviewed-on: https://go-review.googlesource.com/37664Reviewed-by: -
Giovanni Bajo authored
Match more patterns generated by the compiler where the index for a bound check is bounded through a AND operation, with different register sizes. These rules trigger a dozen of times in a bootstrap. Change-Id: Ic9fff16f21d08580f19a366c3ee1a372e58357d1 Reviewed-on: https://go-review.googlesource.com/37442 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently ReadMemStats stops the world for ~1.7 ms/GB of heap because it collects statistics from every single span. For large heaps, this can be quite costly. This is particularly unfortunate because many production infrastructures call this function regularly to collect and report statistics. Fix this by tracking the necessary cumulative statistics in the mcaches. ReadMemStats still has to stop the world to stabilize these statistics, but there are only O(GOMAXPROCS) mcaches to collect statistics from, so this pause is only 25µs even at GOMAXPROCS=100. Fixes #13613. Change-Id: I3c0a4e14833f4760dab675efc1916e73b4c0032a Reviewed-on: https://go-review.googlesource.com/34937 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
