- 05 Jun, 2015 22 commits
-
-
Brad Fitzpatrick authored
Change-Id: I12e6990b46ea9c733a5718dc5ca67f1fcd2dec66 Reviewed-on: https://go-review.googlesource.com/10754Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Change-Id: I09257b8f5482cba10b5f4d3813c778d6e9e74d40 Reviewed-on: https://go-review.googlesource.com/10752Reviewed-by:
Russ Cox <rsc@golang.org>
-
Alexis Imperial-Legrand authored
Change-Id: I95bf62c0f2d77dd67515921e6aefa511cce8d95d Reviewed-on: https://go-review.googlesource.com/10633Reviewed-by:
-
Russ Cox authored
Change-Id: I0e6f1a39b3d6b15d05891c8b25ab6644356bde5f Reviewed-on: https://go-review.googlesource.com/10751Reviewed-by:
-
Aaron Jacobs authored
ContinueOnError is particularly confusing, because it causes FlagSet.Parse to return as soon as it sees an error. I gather that the intent is "continue the program" rather than "continue parsing", compared to exiting or panicking. Change-Id: I27370ce1f321ea4debcee5b03faff3532495c71a Reviewed-on: https://go-review.googlesource.com/10740Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
Actually add all build flags, so we also get things like -race. Fixes #10228. Change-Id: I5f77dda9d1ee3208e1833702f12f68c2731c4b22 Reviewed-on: https://go-review.googlesource.com/10697Reviewed-by:
-
Russ Cox authored
Change-Id: I1d7b728bd161da7bd6dd460862d8be072921e8b9 Reviewed-on: https://go-review.googlesource.com/10763Reviewed-by:
-
Russ Cox authored
Change-Id: If969d7a06c83447ee38da30f1477a6cf4bfa1a03 Reviewed-on: https://go-review.googlesource.com/10691Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Also fix the interaction between -buildmode and -shared. It's okay for -shared to change the default build mode, but it's not okay for it to silently override an explicit -buildmode=exe. Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba Reviewed-on: https://go-review.googlesource.com/10315Reviewed-by:
-
Russ Cox authored
People invoking the linker directly already have to change their scripts to use the new "go tool link", so this is a good time to make the -X flag behave like all other Go flags and take just a single argument. The old syntax will continue to be accepted (it is rewritten into the new syntax before flag parsing). Maybe some day we will be able to retire it. Even if we never retire the old syntax, having the new syntax at least makes the rewriting much less of a kludge. Change-Id: I91e8df94f4c22b2186e81d7f1016b8767d777eac Reviewed-on: https://go-review.googlesource.com/10310Reviewed-by:
-
Russ Cox authored
These are the Go 1.4 docs but refreshed for Go 1.5. The most sigificant change is that all references to the Plan 9 toolchain are gone. The tools no longer bear any meaningful resemblance. Change-Id: I44f5cadb832a982323d7fee0b77673e55d761b35 Reviewed-on: https://go-review.googlesource.com/10298Reviewed-by:
-
Russ Cox authored
Change-Id: I5c991cad38c9e2c839314a56d3415a2aa09c1561 Reviewed-on: https://go-review.googlesource.com/10762Reviewed-by:
-
Russ Cox authored
See golang.org/s/go15gomaxprocs for details. Change-Id: I8de5df34fa01d31d78f0194ec78a2474c281243c Reviewed-on: https://go-review.googlesource.com/10668Reviewed-by:
-
Russ Cox authored
Fixes #10375. Change-Id: I78dc3e12035d130c405bdb284b0cceea19f084f6 Reviewed-on: https://go-review.googlesource.com/10690Reviewed-by:
-
Russ Cox authored
The flag is available from the go test command as -count: % go test -run XXX -bench . -count 3 PASS BenchmarkSprintfEmpty 30000000 54.0 ns/op BenchmarkSprintfEmpty 30000000 51.9 ns/op BenchmarkSprintfEmpty 30000000 53.8 ns/op BenchmarkSprintfString 10000000 238 ns/op BenchmarkSprintfString 10000000 239 ns/op BenchmarkSprintfString 10000000 234 ns/op BenchmarkSprintfInt 10000000 232 ns/op BenchmarkSprintfInt 10000000 226 ns/op BenchmarkSprintfInt 10000000 225 ns/op ... If -cpu is set, each test is run n times for each cpu value. Original by r (CL 10663). Change-Id: If3dfbdf21698952daac9249b5dbca66f5301e91b Reviewed-on: https://go-review.googlesource.com/10669Reviewed-by:
-
Russ Cox authored
Fixes #11048. Fixes #11075. Change-Id: I81f5ef1e1944056ce5494c91aa4a4a63c758f566 Reviewed-on: https://go-review.googlesource.com/10709Reviewed-by:
-
Russ Cox authored
Non-ELF binary formats are much less flexible and typically do not have a good place to store the build ID. We store it as raw bytes at the beginning of the text segment. The only system I know of that will be upset about this is NaCl, and NaCl is an ELF system and does not use this. For #11048. Change-Id: Iaa7ace703c4cf36392e752eea9b55e2ce49e9826 Reviewed-on: https://go-review.googlesource.com/10708Reviewed-by:
-
Russ Cox authored
Other binary formats to follow. For #11048. Change-Id: Ia2d8b47c99c99d171c014b7cfd23c1c7ada5231c Reviewed-on: https://go-review.googlesource.com/10707Reviewed-by:
-
Russ Cox authored
Other binary formats to follow. Using our own note instead of the GNU build ID note because we are not the GNU project, and I can't guarantee that the semantics of our note and the semantics of the GNU note will match forever. (Also they don't match today.) For #11048. Change-Id: Iec7e5a2e49d52b6d3a51b0aface2de7c77a45491 Reviewed-on: https://go-review.googlesource.com/10706Reviewed-by:
-
Russ Cox authored
Change-Id: I3c9b05879fe0b6e94b63e9b65e4411ba2a917134 Reviewed-on: https://go-review.googlesource.com/10705Reviewed-by:
-
Russ Cox authored
Change-Id: I038e892725836ab7718f7638e8ad5712953f2cb5 Reviewed-on: https://go-review.googlesource.com/10704Reviewed-by:
-
Russ Cox authored
The bootstrap restriction is to avoid needing cgo for package net. There's no problem with building debug/elf and debug/dwarf, so do that. An upcoming CL is going to add more note processing code, and it simplifies things not to have to think about the code being missing half the time. Change-Id: I0e2f120ac23f14db6ecfcec7bfe254a69abcf7b6 Reviewed-on: https://go-review.googlesource.com/10703Reviewed-by:
-
- 04 Jun, 2015 18 commits
-
-
Robert Griesemer authored
Change-Id: I4ff42113c5dda553d6f3d58f0e4836dce7c84710 Reviewed-on: https://go-review.googlesource.com/10730Reviewed-by:
-
Rob Pike authored
The go/doc package doesn't remove unexported entries from const and var blocks, so we must trim them ourselves. Fixes #11008 Change-Id: Ibd60d87e09333964e2588340a2ca2b8804bbaa28 Reviewed-on: https://go-review.googlesource.com/10643Reviewed-by:
-
Robert Griesemer authored
- s|"golang.org/x/tools/go/exact"|"go/constant"| - s|"golang.org/x/tools/go/types"|"go/types"| - removed import of gcimporter - import "go/importer" instead - trivial adjustments to make use of go/importer - adjusted import paths for whitelist.go Change-Id: I43488ff44c329cd869c92dcc31193fb31bebfd29 Reviewed-on: https://go-review.googlesource.com/10695Reviewed-by:
-
Robert Griesemer authored
cp -r x/tools/cmd/vet cmd/vet without any changes. The next change will adjust the source to use std repo go/types and friends. This may (temporarily) break the build; the next commit (immediately following) will fix it. We do it in two commits so that we can see the manual changes. Change-Id: Ic45dab7066f13923e21f8c61200c8c3fd447b171 Reviewed-on: https://go-review.googlesource.com/10694Reviewed-by:
-
David Crawshaw authored
As of golang.org/cl/9154, running go test will override a previous go install -a -tags=lldb std with the tag-less version of stdlib. So we pass -tags=lldb into the relevant go test commands. Change-Id: I1c718289d7212373a9383eff53a643f06598f5ed Reviewed-on: https://go-review.googlesource.com/10701Reviewed-by:
-
Brad Fitzpatrick authored
Per RFC 6265. Change-Id: I2b6b145f5d057f96509332509d722602ed9e2bbd Reviewed-on: https://go-review.googlesource.com/10711Reviewed-by:
Brett Slatkin <bslatkin@google.com> Reviewed-by:
Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Also modifies 'dist test' to use that sharding, and removes some old temporary stuff from dist test which are no longer required. 'dist test' now also supports running a list of tests given in arguments, mutually exclusive with the existing -run=REGEXP flag. The hacky fast paths for avoiding the 1 second "go list" latency are now removed and only apply to the case where partial tests are run via args, instead of regex. The build coordinator will use both styles for awhile. (the statically-sharded ARM builders on scaleway will continue to use regexps, but the dynamically-shared builders on GCE will use the list of tests) Updates #10029 Change-Id: I557800a54dfa6f3b5100ef4c26fe397ba5189813 Reviewed-on: https://go-review.googlesource.com/10688Reviewed-by:
-
Josh Bleecher Snyder authored
Static branch prediction guesses that forward branches aren't taken. Since stacks are rarely grown, make the forward branch mean grow. While we're here, remove the debug-only instruction saving the frame size in the temp register. Sample disassembly for func f() { _ = [128]byte{} } Before: 0x4008248 ldr x1, [x28, #0x10] 0x400824c sub x2, sp, #0x90 0x4008250 cmp x2, x1 0x4008254 b.hi 0x4008268 0x4008258 mov x3, x30 0x400825c movz x27, #0x90 0x4008260 bl runtime.morestack_noctxt 0x4008264 b main.f 0x4008268 sub sp, sp, #0x90 0x400826c add x16, sp, #0x10 0x4008270 str xzr, [x16] 0x4008274 str xzr, [x16, #0x8] 0x4008278 str xzr, [x16, #0x10] 0x400827c str xzr, [x16, #0x18] 0x4008280 str xzr, [x16, #0x20] 0x4008284 str xzr, [x16, #0x28] 0x4008288 str xzr, [x16, #0x30] 0x400828c str xzr, [x16, #0x38] 0x4008290 str xzr, [x16, #0x40] 0x4008294 str xzr, [x16, #0x48] 0x4008298 str xzr, [x16, #0x50] 0x400829c str xzr, [x16, #0x58] 0x40082a0 str xzr, [x16, #0x60] 0x40082a4 str xzr, [x16, #0x68] 0x40082a8 str xzr, [x16, #0x70] 0x40082ac str xzr, [x16, #0x78] 0x40082b0 add sp, sp, #0x90 0x40082b4 ret After: 0x4004bc8 ldr x1, [x28, #0x10] 0x4004bcc sub x2, sp, #0x90 0x4004bd0 cmp x2, x1 0x4004bd4 b.ls 0x4004c28 0x4004bd8 sub sp, sp, #0x90 0x4004bdc add x16, sp, #0x10 0x4004be0 str xzr, [x16] 0x4004be4 str xzr, [x16, #0x8] 0x4004be8 str xzr, [x16, #0x10] 0x4004bec str xzr, [x16, #0x18] 0x4004bf0 str xzr, [x16, #0x20] 0x4004bf4 str xzr, [x16, #0x28] 0x4004bf8 str xzr, [x16, #0x30] 0x4004bfc str xzr, [x16, #0x38] 0x4004c00 str xzr, [x16, #0x40] 0x4004c04 str xzr, [x16, #0x48] 0x4004c08 str xzr, [x16, #0x50] 0x4004c0c str xzr, [x16, #0x58] 0x4004c10 str xzr, [x16, #0x60] 0x4004c14 str xzr, [x16, #0x68] 0x4004c18 str xzr, [x16, #0x70] 0x4004c1c str xzr, [x16, #0x78] 0x4004c20 add sp, sp, #0x90 0x4004c24 ret 0x4004c28 mov x3, x30 0x4004c2c bl runtime.morestack_noctxt 0x4004c30 b main.f Updates #10587. Package sort benchmarks using an iPhone 6: name old time/op new time/op delta SearchWrappers 355ns ± 1% 328ns ± 1% -7.57% (p=0.000 n=25+19) SortString1K 580µs ± 1% 577µs ± 1% -0.48% (p=0.000 n=25+25) StableString1K 1.04ms ± 0% 1.04ms ± 0% ~ (p=0.851 n=24+25) SortInt1K 251µs ± 1% 247µs ± 1% -1.52% (p=0.000 n=23+25) StableInt1K 267µs ± 2% 261µs ± 2% -2.02% (p=0.000 n=25+25) SortInt64K 23.8ms ± 1% 23.6ms ± 0% -0.97% (p=0.000 n=25+23) StableInt64K 22.8ms ± 0% 22.4ms ± 1% -1.76% (p=0.000 n=24+25) Sort1e2 123µs ± 1% 124µs ± 1% ~ (p=0.256 n=23+23) Stable1e2 248µs ± 1% 247µs ± 1% -0.69% (p=0.000 n=23+25) Sort1e4 24.3ms ± 2% 24.6ms ± 5% +1.36% (p=0.017 n=22+25) Stable1e4 77.2ms ± 6% 76.2ms ± 5% -1.36% (p=0.020 n=25+25) Sort1e6 3.95s ± 8% 3.95s ± 8% ~ (p=0.863 n=25+25) Stable1e6 15.7s ± 1% 15.5s ± 1% -1.11% (p=0.000 n=22+23) Change-Id: I377b3817af2ed27ddeecf24edef97fad91fc1afc Reviewed-on: https://go-review.googlesource.com/10500Reviewed-by:Dave Cheney <dave@cheney.net>
-
Josh Bleecher Snyder authored
When stack growth is not needed, as it usually is not, execute only a single conditional branch rather than three conditional instructions. This adds 4 bytes to every function, but might speed up execution in the common case. Sample disassembly for func f() { _ = [128]byte{} } Before: TEXT main.f(SB) x.go x.go:3 0x2000 e59a1008 MOVW 0x8(R10), R1 x.go:3 0x2004 e59fb028 MOVW 0x28(R15), R11 x.go:3 0x2008 e08d200b ADD R11, R13, R2 x.go:3 0x200c e1520001 CMP R1, R2 x.go:3 0x2010 91a0300e MOVW.LS R14, R3 x.go:3 0x2014 9b0118a9 BL.LS runtime.morestack_noctxt(SB) x.go:3 0x2018 9afffff8 B.LS main.f(SB) x.go:3 0x201c e52de084 MOVW.W R14, -0x84(R13) x.go:4 0x2020 e28d1004 ADD $4, R13, R1 x.go:4 0x2024 e3a00000 MOVW $0, R0 x.go:4 0x2028 eb012255 BL 0x4a984 x.go:5 0x202c e49df084 RET #132 x.go:5 0x2030 eafffffe B 0x2030 x.go:5 0x2034 ffffff7c ? After: TEXT main.f(SB) x.go x.go:3 0x2000 e59a1008 MOVW 0x8(R10), R1 x.go:3 0x2004 e59fb02c MOVW 0x2c(R15), R11 x.go:3 0x2008 e08d200b ADD R11, R13, R2 x.go:3 0x200c e1520001 CMP R1, R2 x.go:3 0x2010 9a000004 B.LS 0x2028 x.go:3 0x2014 e52de084 MOVW.W R14, -0x84(R13) x.go:4 0x2018 e28d1004 ADD $4, R13, R1 x.go:4 0x201c e3a00000 MOVW $0, R0 x.go:4 0x2020 eb0124dc BL 0x4b398 x.go:5 0x2024 e49df084 RET #132 x.go:5 0x2028 e1a0300e MOVW R14, R3 x.go:5 0x202c eb011b0d BL runtime.morestack_noctxt(SB) x.go:5 0x2030 eafffff2 B main.f(SB) x.go:5 0x2034 eafffffe B 0x2034 x.go:5 0x2038 ffffff7c ? Updates #10587. package sort benchmarks on an iPhone 6: name old time/op new time/op delta SortString1K 569µs ± 0% 565µs ± 1% -0.75% (p=0.000 n=23+24) StableString1K 872µs ± 1% 870µs ± 1% -0.16% (p=0.009 n=23+24) SortInt1K 317µs ± 2% 316µs ± 2% ~ (p=0.410 n=26+26) StableInt1K 343µs ± 1% 339µs ± 1% -1.07% (p=0.000 n=22+23) SortInt64K 30.0ms ± 1% 30.0ms ± 1% ~ (p=0.091 n=25+24) StableInt64K 30.2ms ± 0% 30.0ms ± 0% -0.69% (p=0.000 n=22+22) Sort1e2 147µs ± 1% 146µs ± 0% -0.48% (p=0.000 n=25+24) Stable1e2 290µs ± 1% 286µs ± 1% -1.30% (p=0.000 n=23+24) Sort1e4 29.5ms ± 2% 29.7ms ± 1% +0.71% (p=0.000 n=23+23) Stable1e4 88.7ms ± 4% 88.6ms ± 8% -0.07% (p=0.022 n=26+26) Sort1e6 4.81s ± 7% 4.83s ± 7% ~ (p=0.192 n=26+26) Stable1e6 18.3s ± 1% 18.1s ± 1% -0.76% (p=0.000 n=25+23) SearchWrappers 318ns ± 1% 344ns ± 1% +8.14% (p=0.000 n=23+26) package sort benchmarks on a first generation rpi: name old time/op new time/op delta SearchWrappers 4.13µs ± 0% 3.95µs ± 0% -4.42% (p=0.000 n=15+13) SortString1K 5.81ms ± 1% 5.82ms ± 2% ~ (p=0.400 n=14+15) StableString1K 9.69ms ± 1% 9.73ms ± 0% ~ (p=0.121 n=15+11) SortInt1K 3.30ms ± 2% 3.66ms ±19% +10.82% (p=0.000 n=15+14) StableInt1K 5.97ms ±15% 4.17ms ± 8% -30.05% (p=0.000 n=15+15) SortInt64K 319ms ± 1% 295ms ± 1% -7.65% (p=0.000 n=15+15) StableInt64K 343ms ± 0% 332ms ± 0% -3.26% (p=0.000 n=12+13) Sort1e2 3.36ms ± 2% 3.22ms ± 4% -4.10% (p=0.000 n=15+15) Stable1e2 6.74ms ± 1% 6.43ms ± 2% -4.67% (p=0.000 n=15+15) Sort1e4 247ms ± 1% 247ms ± 1% ~ (p=0.331 n=15+14) Stable1e4 864ms ± 0% 820ms ± 0% -5.15% (p=0.000 n=14+15) Sort1e6 41.2s ± 0% 41.2s ± 0% +0.15% (p=0.000 n=13+14) Stable1e6 192s ± 0% 182s ± 0% -5.07% (p=0.000 n=14+14) Change-Id: I8a9db77e1d4ea1956575895893bc9d04bd81204b Reviewed-on: https://go-review.googlesource.com/10497Reviewed-by: -
Josh Bleecher Snyder authored
Static branch prediction guesses that forward branches aren't taken. Since stacks are rarely grown, make the forward branch mean grow. Sample disassembly for func f() { _ = [128]byte{} } Before: TEXT main.f(SB) x.go x.go:3 0x2000 65488b0c25a0080000 GS MOVQ GS:0x8a0, CX x.go:3 0x2009 483b6110 CMPQ 0x10(CX), SP x.go:3 0x200d 7707 JA 0x2016 x.go:3 0x200f e88c410400 CALL runtime.morestack_noctxt(SB) x.go:3 0x2014 ebea JMP main.f(SB) x.go:3 0x2016 4881ec80000000 SUBQ $0x80, SP x.go:4 0x201d 488d3c24 LEAQ 0(SP), DI x.go:4 0x2021 31c0 XORL AX, AX x.go:4 0x2023 e8cc640400 CALL 0x484f4 x.go:5 0x2028 4881c480000000 ADDQ $0x80, SP x.go:5 0x202f c3 RET After: TEXT main.f(SB) x.go x.go:3 0x2000 65488b0c25a0080000 GS MOVQ GS:0x8a0, CX x.go:3 0x2009 483b6110 CMPQ 0x10(CX), SP x.go:3 0x200d 761a JBE 0x2029 x.go:3 0x200f 4881ec80000000 SUBQ $0x80, SP x.go:4 0x2016 488d3c24 LEAQ 0(SP), DI x.go:4 0x201a 31c0 XORL AX, AX x.go:4 0x201c e813740400 CALL 0x49434 x.go:5 0x2021 4881c480000000 ADDQ $0x80, SP x.go:5 0x2028 c3 RET x.go:3 0x2029 e8224f0400 CALL runtime.morestack_noctxt(SB) x.go:3 0x202e ebd0 JMP main.f(SB) Updates #10587. Sample benchmarks on a 2.8 GHz Intel Core i7: package sort name old mean new mean delta SearchWrappers 134ns × (0.99,1.01) 132ns × (0.99,1.01) -1.73% (p=0.000 n=15+14) SortString1K 215µs × (0.99,1.01) 213µs × (0.99,1.01) -0.61% (p=0.020 n=14+15) StableString1K 311µs × (0.99,1.02) 309µs × (0.99,1.02) ~ (p=0.077 n=14+15) SortInt1K 103µs × (0.99,1.02) 100µs × (0.98,1.01) -3.34% (p=0.000 n=15+15) StableInt1K 102µs × (0.99,1.01) 98µs × (0.97,1.04) -3.53% (p=0.000 n=15+15) SortInt64K 10.1ms × (0.98,1.02) 9.7ms × (0.99,1.01) -3.86% (p=0.000 n=14+15) StableInt64K 8.70ms × (0.99,1.01) 8.44ms × (0.99,1.03) -2.93% (p=0.000 n=14+15) Sort1e2 51.2µs × (1.00,1.01) 48.9µs × (0.99,1.02) -4.48% (p=0.000 n=13+15) Stable1e2 100µs × (0.99,1.02) 99µs × (0.99,1.01) -1.15% (p=0.000 n=14+13) Sort1e4 11.1ms × (0.99,1.02) 10.4ms × (0.99,1.01) -6.02% (p=0.000 n=15+14) Stable1e4 30.6ms × (0.99,1.01) 30.3ms × (0.99,1.02) -1.02% (p=0.001 n=15+14) Sort1e6 1.75s × (0.99,1.02) 1.66s × (0.98,1.03) -4.95% (p=0.000 n=14+15) Stable1e6 6.31s × (0.99,1.01) 6.26s × (0.99,1.01) -0.79% (p=0.002 n=15+15) package regexp name old mean new mean delta Literal 131ns × (0.99,1.01) 130ns × (0.99,1.03) -1.07% (p=0.004 n=14+15) NotLiteral 2.13µs × (0.99,1.01) 2.01µs × (0.99,1.03) -5.71% (p=0.000 n=14+14) MatchClass 3.15µs × (0.99,1.01) 3.04µs × (0.99,1.02) -3.40% (p=0.000 n=15+15) MatchClass_InRange 2.92µs × (0.99,1.01) 2.77µs × (0.99,1.02) -5.05% (p=0.000 n=13+15) ReplaceAll 2.17µs × (0.99,1.02) 2.06µs × (0.99,1.01) -5.19% (p=0.000 n=15+13) AnchoredLiteralShortNonMatch 116ns × (0.99,1.02) 113ns × (0.99,1.01) -2.75% (p=0.000 n=15+14) AnchoredLiteralLongNonMatch 125ns × (0.99,1.01) 127ns × (0.98,1.02) +1.49% (p=0.000 n=15+15) AnchoredShortMatch 178ns × (0.99,1.02) 175ns × (0.99,1.01) -1.62% (p=0.000 n=15+13) AnchoredLongMatch 328ns × (0.99,1.00) 341ns × (0.99,1.01) +3.73% (p=0.000 n=12+15) OnePassShortA 773ns × (0.99,1.02) 752ns × (0.99,1.01) -2.78% (p=0.000 n=15+13) NotOnePassShortA 794ns × (0.99,1.03) 780ns × (0.99,1.02) -1.75% (p=0.001 n=15+15) OnePassShortB 608ns × (0.99,1.01) 591ns × (0.99,1.02) -2.86% (p=0.000 n=15+14) NotOnePassShortB 576ns × (0.99,1.01) 571ns × (0.99,1.02) -0.74% (p=0.035 n=15+15) OnePassLongPrefix 131ns × (0.99,1.02) 130ns × (0.99,1.02) -1.32% (p=0.003 n=15+15) OnePassLongNotPrefix 503ns × (0.99,1.02) 481ns × (0.99,1.01) -4.34% (p=0.000 n=15+13) MatchEasy0_32 102ns × (0.98,1.01) 101ns × (0.99,1.02) ~ (p=0.907 n=15+14) MatchEasy0_1K 617ns × (0.99,1.02) 634ns × (0.98,1.02) +2.77% (p=0.000 n=15+15) MatchEasy0_32K 10.9µs × (0.99,1.01) 11.1µs × (0.99,1.01) +1.59% (p=0.000 n=15+15) MatchEasy0_1M 406µs × (0.99,1.02) 410µs × (0.99,1.02) +1.01% (p=0.000 n=14+15) MatchEasy0_32M 13.4ms × (0.99,1.01) 13.7ms × (0.99,1.02) +1.64% (p=0.000 n=12+15) MatchEasy1_32 83.7ns × (0.98,1.02) 83.0ns × (0.98,1.02) ~ (p=0.190 n=15+15) MatchEasy1_1K 1.46µs × (0.99,1.02) 1.39µs × (0.99,1.02) -4.83% (p=0.000 n=15+15) MatchEasy1_32K 49.4µs × (0.99,1.01) 49.4µs × (0.99,1.01) ~ (p=0.205 n=15+15) MatchEasy1_1M 1.72ms × (0.99,1.02) 1.75ms × (0.99,1.01) +1.34% (p=0.000 n=15+15) MatchEasy1_32M 55.5ms × (0.99,1.01) 56.1ms × (0.99,1.02) +1.10% (p=0.002 n=15+15) MatchMedium_32 1.37µs × (0.99,1.04) 1.33µs × (0.99,1.01) -2.87% (p=0.000 n=15+15) MatchMedium_1K 41.1µs × (0.99,1.02) 40.4µs × (0.99,1.02) -1.59% (p=0.000 n=15+15) MatchMedium_32K 1.71ms × (0.99,1.01) 1.75ms × (0.99,1.02) +2.36% (p=0.000 n=14+15) MatchMedium_1M 54.5ms × (0.99,1.01) 56.1ms × (0.99,1.01) +2.94% (p=0.000 n=13+15) MatchMedium_32M 1.75s × (0.99,1.01) 1.80s × (0.99,1.01) +2.77% (p=0.000 n=15+15) MatchHard_32 2.12µs × (0.99,1.02) 2.06µs × (0.99,1.01) -2.60% (p=0.000 n=15+14) MatchHard_1K 64.4µs × (0.98,1.02) 62.2µs × (0.99,1.01) -3.33% (p=0.000 n=15+15) MatchHard_32K 2.74ms × (0.99,1.01) 2.75ms × (0.99,1.01) ~ (p=0.310 n=15+14) MatchHard_1M 87.1ms × (0.99,1.02) 88.2ms × (0.99,1.01) +1.36% (p=0.000 n=14+15) MatchHard_32M 2.79s × (0.99,1.02) 2.83s × (0.99,1.02) +1.26% (p=0.004 n=15+14) go1 benchmarks name old time/op new time/op delta BinaryTree17 3.34s ± 3% 3.28s ± 2% -1.86% (p=0.000 n=67+66) Fannkuch11 2.50s ± 1% 2.51s ± 1% +0.24% (p=0.016 n=63+66) FmtFprintfEmpty 50.3ns ± 1% 50.2ns ± 2% -0.30% (p=0.001 n=62+67) FmtFprintfString 178ns ± 1% 166ns ± 1% -7.10% (p=0.000 n=62+59) FmtFprintfInt 168ns ± 1% 161ns ± 2% -4.41% (p=0.000 n=66+64) FmtFprintfIntInt 292ns ± 1% 282ns ± 2% -3.55% (p=0.000 n=62+60) FmtFprintfPrefixedInt 245ns ± 2% 239ns ± 2% -2.24% (p=0.000 n=66+65) FmtFprintfFloat 338ns ± 2% 326ns ± 1% -3.42% (p=0.000 n=64+59) FmtManyArgs 1.14µs ± 1% 1.10µs ± 2% -3.55% (p=0.000 n=62+62) GobDecode 8.88ms ± 2% 8.74ms ± 1% -1.55% (p=0.000 n=66+62) GobEncode 6.84ms ± 2% 6.61ms ± 2% -3.32% (p=0.000 n=61+67) Gzip 356ms ± 2% 352ms ± 2% -1.07% (p=0.000 n=67+66) Gunzip 90.6ms ± 2% 89.8ms ± 1% -0.83% (p=0.000 n=65+64) HTTPClientServer 82.6µs ± 2% 82.5µs ± 2% ~ (p=0.832 n=65+63) JSONEncode 17.5ms ± 2% 16.8ms ± 2% -3.77% (p=0.000 n=63+63) JSONDecode 63.3ms ± 2% 59.0ms ± 2% -6.85% (p=0.000 n=64+63) Mandelbrot200 3.85ms ± 1% 3.85ms ± 1% ~ (p=0.127 n=65+62) GoParse 3.75ms ± 2% 3.66ms ± 2% -2.39% (p=0.000 n=66+64) RegexpMatchEasy0_32 100ns ± 2% 100ns ± 1% -0.65% (p=0.000 n=62+64) RegexpMatchEasy0_1K 342ns ± 1% 341ns ± 1% -0.43% (p=0.000 n=65+64) RegexpMatchEasy1_32 82.8ns ± 2% 82.8ns ± 2% ~ (p=0.977 n=63+64) RegexpMatchEasy1_1K 511ns ± 2% 506ns ± 2% -1.01% (p=0.000 n=63+64) RegexpMatchMedium_32 139ns ± 1% 134ns ± 3% -3.27% (p=0.000 n=59+60) RegexpMatchMedium_1K 41.8µs ± 2% 40.5µs ± 2% -3.05% (p=0.000 n=62+64) RegexpMatchHard_32 2.13µs ± 1% 2.09µs ± 1% -2.22% (p=0.000 n=60+65) RegexpMatchHard_1K 64.4µs ± 3% 62.8µs ± 2% -2.58% (p=0.000 n=65+59) Revcomp 531ms ± 2% 529ms ± 1% -0.28% (p=0.022 n=61+61) Template 73.2ms ± 1% 73.1ms ± 1% ~ (p=0.794 n=66+63) TimeParse 369ns ± 1% 352ns ± 1% -4.68% (p=0.000 n=65+66) TimeFormat 374ns ± 2% 348ns ± 2% -7.01% (p=0.000 n=66+64) Change-Id: Ib190b5bb48a3e9087711d9e3383621d3103dd342 Reviewed-on: https://go-review.googlesource.com/10367Reviewed-by: -
Hajime Hoshi authored
This CL resets the parent stack when printing a character or comment field struct. In the case of XML elements, the previous parents stack must be considered. However, charadata or comment fields can't be printed in other fields so it seems required to reset the parent stack each time a chardata or comment field is printed. Fixes #5072 Change-Id: I84f61c9bfce94133cd0c076c11211b9be5b4b1ac Reviewed-on: https://go-review.googlesource.com/9910Reviewed-by:
Nigel Tao <nigeltao@golang.org> Reviewed-by:
roger peppe <rogpeppe@gmail.com>
-
Russ Cox authored
If 'go install' (with no arguments, meaning the current directory) succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind during a sequence like: go build <test, mostly works, make small change> go install Before this CL, the current directory still has the stale binary from 'go build'. If $PATH contains dot, running the name of the program will find this stale binary instead of the new, installed one. Remove the 'go build' target during 'go install', both to clean up the directory and to avoid accidentally running the stale binary. Another way to view this CL is that it makes the go command behave as if 'go install' is implemented by 'go build' followed by moving the resulting binary to the install location. See #9645 for discussion and objections. Fixes #9645. Change-Id: Ide109572f96bbb5a35be45dda17738317462a7d4 Reviewed-on: https://go-review.googlesource.com/10682Reviewed-by:
-
Russ Cox authored
We used to put a rebuilding barrier between GOPATHs, so that if you had GOPATH=dir1:dir2 and you had "p" in dir1/src/p and "q" in dir2/src/q, with "p" importing "q", then when you ran 'go install p', it would see that it was working in dir1 and (since nothing from dir2 was explicitly mentioned) would assume that everything in dir2 is up-to-date, provided it is built at all. This has the confusing behavior that if "q" hasn't been built ever, then if you update sources in q and run 'go install p', the right thing happens (q is rebuilt and then p), but after that, if you update sources in q and run 'go install p', nothing happens: the installed q is assumed up-to-date. People using code conventions with multiple GOPATH entries (for example, with commands in one place and libraries in another, or vendoring conventions that try to avoid rewriting import paths) run into this without realizing it and end up with incorrect build results. The original motivation here was to avoid rebuild standard packages since a system-installed GOROOT might be unwritable. The change introduced to separate GOROOT also separated individual GOPATH entries. Later changes added a different, more aggressive earlier shortcut for GOROOT in release settings, so the code here is now only applying to (and confusing) multiple GOPATH entries. Remove it. Fixes #10509. Change-Id: I687a3baa81eff4073b0d67f9acbc5a3ab192eda5 Reviewed-on: https://go-review.googlesource.com/9155Reviewed-by:
-
Russ Cox authored
The go command uses file modification times to decide when a package is out of date: if the .a file is older than a source file, the .a file needs to be rebuilt. This scheme breaks down when multiple source files compile into a single .a file: if one source file is removed but no other changes are made, there is no indication that the .a file is out of date. The fix is to store a value called a build ID in the package archive itself. The build ID is a hash of the names of all source files compiled into the package. A later go command can read the build ID out of the package archive and compare to the build ID derived from the list of source files it now sees in the directory. If the build IDs differ, the file list has changed, and the package must be rebuilt. There is a cost here: when scanning a package directory, in addition to reading the beginning of every source file for build tags and imports, the go command now also reads the beginning of the associated package archive, for the build ID. This is at most a doubling in the number of files read. On my 2012 MacBook Pro, the time for 'go list std' increases from about 0.215 seconds to about 0.23 seconds. For executable binaries, the approach is the same except that the build ID information is stored in a trailer at the end of the executable file. It remains to be seen if anything objects to the trailer. I don't expect problems except maybe on Plan 9. Fixes #3895. Change-Id: I21b4ebf5890c1a39e4a013eabe1ddbb5f3510c04 Reviewed-on: https://go-review.googlesource.com/9154Reviewed-by:
-
Russ Cox authored
$ sizeof -p cmd/compile/internal/gc Node Node 144 $ Change-Id: I688e3790964fe42f48c19f697ec38094a92fe1c1 Reviewed-on: https://go-review.googlesource.com/10531Reviewed-by:
-
Russ Cox authored
Suggested during code reviews of last 15 CLs (or so). Change-Id: If780f6eb47a7a31df133c64d5dcf0eaf04d8447b Reviewed-on: https://go-review.googlesource.com/10675Reviewed-by:
-
Josh Bleecher Snyder authored
stkcheck is flow-insensitive: It processes calls in PC order. Since morestack was always the first call in a function, it was a safe, conservative approximation to simply adjust stack space as we went, recognizing morestack when it showed up. Subsequent CLS will rearrange the function prologue; morestack may no longer be the first call in a function. Introducing flow-sensitivity to stkcheck would allow this, and possibly allow a smaller stackguard. It is also a high risk change and possibly expensive. Instead, assume that all calls to morestack occur as part of the function prologue, no matter where they are located in the program text. Updates #10587. Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f Reviewed-on: https://go-review.googlesource.com/10496 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #10209. Change-Id: I248434f9195c868befd1ed8a6000a9cac72d1df8 Reviewed-on: https://go-review.googlesource.com/10263Reviewed-by:
-
