- 09 Sep, 2016 14 commits
-
-
Matthew Dempsky authored
cmd/compile already optimizes "string(b) == s" to avoid allocating a temporary string. Change-Id: I4244fbeae8d350261494135c357f9a6e2ab7ace3 Reviewed-on: https://go-review.googlesource.com/28931 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Crawshaw authored
Moves the grouping of symbol kinds (sections) into cmd/internal/obj to keep it near the definition. Groundwork for CL 28538. Change-Id: I99112981e69b028f366e1333f31cd7defd4ff82c Reviewed-on: https://go-review.googlesource.com/28691 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
As cmd/internal/obj is coordinating the definition of GOOS, GOARCH, etc across the compiler and linker, turn its functions into globals and use them everywhere. Change-Id: I5db5addda3c6b6435c37fd5581c7c3d9a561f492 Reviewed-on: https://go-review.googlesource.com/28854 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Tormod Erevik Lea authored
Change-Id: Ic5160edbbca4a8ffc7c7e6246e34fae1978470fd Reviewed-on: https://go-review.googlesource.com/28912Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Crawshaw authored
Separate out windows/windowsgui properly so we are not encoding some of the Headtype value in a separate headstring global. Remove one of the two copies of the variable from cmd/link. Remove duplicate string to headtype list. Change-Id: Ifa20fb9652a1dc95161e154aac11f15ad0f709d0 Reviewed-on: https://go-review.googlesource.com/28853 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
The -shared flag has been superseded by the -buildmode flag. Change-Id: I3682cc0367b919084c280d7dc64746485c1d4ddd Reviewed-on: https://go-review.googlesource.com/28852 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Dhaivat Pandit authored
Fixes #16884 Updates #16360 Change-Id: I01563031a1c105e54499134eed4789f6219f41ec Reviewed-on: https://go-review.googlesource.com/27993Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jack Lindamood authored
Modifies context package to use map[]struct{} rather than map[]bool, since the map is intended as a set object. Also adds Benchmarks to the context package switching between different types of root nodes and a tree with different depths. Included below are bytes deltas between the old and new code, using these benchmarks. benchmark old bytes new bytes delta BenchmarkContextCancelTree/depth=1/Root=Background-8 176 176 +0.00% BenchmarkContextCancelTree/depth=1/Root=OpenCanceler-8 560 544 -2.86% BenchmarkContextCancelTree/depth=1/Root=ClosedCanceler-8 352 352 +0.00% BenchmarkContextCancelTree/depth=10/Root=Background-8 3632 3488 -3.96% BenchmarkContextCancelTree/depth=10/Root=OpenCanceler-8 4016 3856 -3.98% BenchmarkContextCancelTree/depth=10/Root=ClosedCanceler-8 1936 1936 +0.00% BenchmarkContextCancelTree/depth=100/Root=Background-8 38192 36608 -4.15% BenchmarkContextCancelTree/depth=100/Root=OpenCanceler-8 38576 36976 -4.15% BenchmarkContextCancelTree/depth=100/Root=ClosedCanceler-8 17776 17776 +0.00% BenchmarkContextCancelTree/depth=1000/Root=Background-8 383792 367808 -4.16% BenchmarkContextCancelTree/depth=1000/Root=OpenCanceler-8 384176 368176 -4.16% BenchmarkContextCancelTree/depth=1000/Root=ClosedCanceler-8 176176 176176 +0.00% Change-Id: I699ad704d9f7b461214e1651d24941927315b525 Reviewed-on: https://go-review.googlesource.com/25270Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Currently the footnote says "gcc is required only if you plan to use cgo", but the footnote was referenced from the text: "use the clang or gcc† that comes with Xcode‡ for cgo support" That seems to imply that clang doesn't get you cgo support on OS X, which isn't true. The update text matches what the install-source.html page says. Change-Id: Ib88464a0d138227d357033123f6675a77d5d777f Reviewed-on: https://go-review.googlesource.com/28786Reviewed-by: Minux Ma <minux@golang.org>
-
Nigel Tao authored
Benchmarks are much better for opaque fills and slightly worse on non opaque fills. I think that on balance, this is still a win. When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0xff}): name old time/op new time/op delta FillOver-8 966µs ± 1% 32µs ± 1% -96.67% (p=0.000 n=10+10) FillSrc-8 32.4µs ± 1% 32.2µs ± 1% ~ (p=0.053 n=9+10) When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0x44}): name old time/op new time/op delta FillOver-8 962µs ± 0% 1018µs ± 0% +5.85% (p=0.000 n=9+10) FillSrc-8 32.2µs ± 1% 32.1µs ± 0% ~ (p=0.148 n=10+10) Change-Id: I52ec6d5fcd0fbc6710cef0e973a21ee7827c0dd9 Reviewed-on: https://go-review.googlesource.com/28790Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
First step towards cleaning up format use. Not yet enabled. Change-Id: Ia8d76bf02fe05882fffb9d17c9a30dc38d28bf81 Reviewed-on: https://go-review.googlesource.com/28784Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Michael Munday authored
STFLE does not necessarily write to all the double-words that are requested. It is therefore necessary to clear the target memory before calling STFLE in order to ensure that the facility list does not contain false positives. Fixes #17032. Change-Id: I7bec9ade7103e747b72f08562fe57e6f091bd89f Reviewed-on: https://go-review.googlesource.com/28850Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
Use MOVW, instead of MOVV, to pass an int32 arg. Also no need to restore arg registers. Fix big-endian MIPS64 build. Change-Id: Ib43c71075c988153e5e5c5c6e7297b3fee28652a Reviewed-on: https://go-review.googlesource.com/28830Reviewed-by: Minux Ma <minux@golang.org>
-
Jim Kingdon authored
It is better to document what golang does, rather than how it differs from languages which readers may or may not know. That the output format is based on the type is basically self-evident if you consider this just in go terms. Change-Id: I0223e9b4cb67cc83a9ebe4d424e6c151d7ed600f Reviewed-on: https://go-review.googlesource.com/28393Reviewed-by: Rob Pike <r@golang.org>
-
- 08 Sep, 2016 26 commits
-
-
Dave Day authored
Currently, path resolution is done using the un-escaped version of paths. This means that path elements like one%2ftwo%2fthree are handled incorrectly, and optional encodings (%2d vs. -) are dropped. This function makes escaped handling consistent with Parse: provided escapings are honoured, and RawPath is only set if necessary. A helper method setPath is introduced to handle the correct setting of Path and RawPath given the encoded path. Fixes #16947 Change-Id: I40b1215e9066e88ec868b41635066eee220fde37 Reviewed-on: https://go-review.googlesource.com/28343 Run-TryBot: Dave Day <djd@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Introduced by https://go-review.googlesource.com/#/c/28331/ . Change-Id: Id75aed6410f06b302d5347f6ca6a2e19c61f6fb6 Reviewed-on: https://go-review.googlesource.com/28779Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I9c0da13d21551dbf766156472224370ab9badfe9 Reviewed-on: https://go-review.googlesource.com/28778 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: Ie73fb460a3838c6d1b9348965a8b69c1bfa6a882 Reviewed-on: https://go-review.googlesource.com/28341Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dave Cheney <dave@cheney.net>
-
Robert Griesemer authored
Change-Id: I9a6e5b9cbcfc264c61fd39ed65330ca737707e1f Reviewed-on: https://go-review.googlesource.com/28340Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: Iac3a72cb6c5394f3c1a49f39125b0256d570e006 Reviewed-on: https://go-review.googlesource.com/28339Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: Icd83e88fc879b30b34f8697d540619efeb25c25b Reviewed-on: https://go-review.googlesource.com/28338Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: If6c2d469c66a7aa8471bf54310354efdac3e0235 Reviewed-on: https://go-review.googlesource.com/28337Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: Iac87007af4ee268b45f11ec05bf4757f2e7eedd8 Reviewed-on: https://go-review.googlesource.com/28336Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I80ed668cdeab0c4342b734d34b429927e0213e5a Reviewed-on: https://go-review.googlesource.com/28335Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I0c362edba66c763e84990e3c5508013021f3e6fe Reviewed-on: https://go-review.googlesource.com/28334Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I878ac549430abc7859c30d176d52d52ce02c5827 Reviewed-on: https://go-review.googlesource.com/28333Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: Id56e886793161b48b445439e9a12109142064d3f Reviewed-on: https://go-review.googlesource.com/28332Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I59e18fab37fd688fc1e578e2192e32e29fdf37f0 Reviewed-on: https://go-review.googlesource.com/28331Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I44ee5843bb9dfd65b9a18091f365355e84888f21 Reviewed-on: https://go-review.googlesource.com/28330Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
So we can submit a sequence of older changes that don't yet update the formats in this file. We will then re-enable the test with the updated formats. Change-Id: I6ed559b83adc891bbf4b3d855a7dc1e428366f7f Reviewed-on: https://go-review.googlesource.com/28776Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Emmanuel Odeke authored
Fixes #11254. Updates #16360. Implements examples using all exported functions. This CL also updates Decode documentation to state that only hexadecimal characters are accepted in the source slice src, but also that the length of src must be even. Change-Id: Id016a4ba814f940cd300f26581fb4b9d2aded306 Reviewed-on: https://go-review.googlesource.com/28482Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
Change-Id: Ia5bf72b70e6f6522d6fb8cd050e78f862d37b5ae Reviewed-on: https://go-review.googlesource.com/27936 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Sina Siadat authored
Hop-by-hop headers (explicitly mentioned in RFC 2616) were already removed from the response. This removes the custom hop-by-hop headers listed in the "Connection" header of the response. Updates #16875 Change-Id: I6b8f261d38b8d72040722f3ded29755ef0303427 Reviewed-on: https://go-review.googlesource.com/28810Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Kevin Burke authored
The previous check for characters inside of a JSON string that needed to be escaped performed seven different boolean comparisons before determining that a ASCII character did not need to be escaped. Most characters do not need to be escaped, so this check can be done in a more performant way. Use the same strategy as the unicode package for precomputing a range of characters that need to be escaped, then do a single lookup into a character array to determine whether the character needs escaping. On an AWS c4.large node: $ benchstat benchmarks/master-bench benchmarks/json-table-bench name old time/op new time/op delta CodeEncoder-2 19.0ms ± 0% 15.5ms ± 1% -18.16% (p=0.000 n=19+20) CodeMarshal-2 20.1ms ± 1% 16.8ms ± 2% -16.35% (p=0.000 n=20+21) CodeDecoder-2 49.3ms ± 1% 49.5ms ± 2% ~ (p=0.498 n=16+20) DecoderStream-2 416ns ± 0% 416ns ± 1% ~ (p=0.978 n=19+19) CodeUnmarshal-2 51.0ms ± 1% 50.9ms ± 1% ~ (p=0.490 n=19+17) CodeUnmarshalReuse-2 48.5ms ± 2% 48.5ms ± 2% ~ (p=0.989 n=20+19) UnmarshalString-2 541ns ± 1% 532ns ± 1% -1.75% (p=0.000 n=20+21) UnmarshalFloat64-2 485ns ± 1% 481ns ± 1% -0.92% (p=0.000 n=20+21) UnmarshalInt64-2 429ns ± 1% 427ns ± 1% -0.49% (p=0.000 n=19+20) Issue10335-2 631ns ± 1% 619ns ± 1% -1.84% (p=0.000 n=20+20) NumberIsValid-2 19.1ns ± 0% 19.1ns ± 0% ~ (all samples are equal) NumberIsValidRegexp-2 689ns ± 1% 690ns ± 0% ~ (p=0.150 n=20+20) SkipValue-2 14.0ms ± 0% 14.0ms ± 0% -0.05% (p=0.000 n=18+18) EncoderEncode-2 525ns ± 2% 512ns ± 1% -2.33% (p=0.000 n=20+18) name old speed new speed delta CodeEncoder-2 102MB/s ± 0% 125MB/s ± 1% +22.20% (p=0.000 n=19+20) CodeMarshal-2 96.6MB/s ± 1% 115.6MB/s ± 2% +19.56% (p=0.000 n=20+21) CodeDecoder-2 39.3MB/s ± 1% 39.2MB/s ± 2% ~ (p=0.464 n=16+20) CodeUnmarshal-2 38.1MB/s ± 1% 38.1MB/s ± 1% ~ (p=0.525 n=19+17) SkipValue-2 143MB/s ± 0% 143MB/s ± 0% +0.05% (p=0.000 n=18+18) I also took the data set reported in #5683 (browser telemetry data from Mozilla), added named structs for the data set, and turned it into a proper benchmark: https://github.com/kevinburke/jsonbench/blob/master/go/bench_test.go The results from that test are similarly encouraging. On a 64-bit Mac: $ benchstat benchmarks/master-benchmark benchmarks/json-table-benchmark name old time/op new time/op delta CodeMarshal-4 1.19ms ± 2% 1.08ms ± 2% -9.33% (p=0.000 n=21+17) Unmarshal-4 3.09ms ± 3% 3.06ms ± 1% -0.83% (p=0.027 n=22+17) UnmarshalReuse-4 3.04ms ± 1% 3.04ms ± 1% ~ (p=0.169 n=20+15) name old speed new speed delta CodeMarshal-4 80.3MB/s ± 1% 88.5MB/s ± 1% +10.29% (p=0.000 n=21+17) Unmarshal-4 31.0MB/s ± 2% 31.2MB/s ± 1% +0.83% (p=0.025 n=22+17) On the c4.large: $ benchstat benchmarks/master-bench benchmarks/json-table-bench name old time/op new time/op delta CodeMarshal-2 1.10ms ± 1% 0.98ms ± 1% -10.12% (p=0.000 n=20+54) Unmarshal-2 2.82ms ± 1% 2.79ms ± 0% -1.09% (p=0.000 n=20+51) UnmarshalReuse-2 2.80ms ± 0% 2.77ms ± 0% -1.03% (p=0.000 n=20+52) name old speed new speed delta CodeMarshal-2 87.3MB/s ± 1% 97.1MB/s ± 1% +11.27% (p=0.000 n=20+54) Unmarshal-2 33.9MB/s ± 1% 34.2MB/s ± 0% +1.10% (p=0.000 n=20+51) For what it's worth, I tried other heuristics - short circuiting the conditional for common ASCII characters, for example: if (b >= 63 && b != 92) || (b >= 39 && b <= 59) || (rest of the conditional) This offered a speedup around 7-9%, not as large as the submitted change. Change-Id: Idcf88f7b93bfcd1164cdd6a585160b7e407a0d9b Reviewed-on: https://go-review.googlesource.com/24466Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
Remove the runeBytes buffer and write the utf8 encoding directly to the internal buf byte slice. name old time/op new time/op delta WriteRune-4 80.5µs ± 2% 57.1µs ± 2% -29.06% (p=0.000 n=20+20) name old speed new speed delta WriteRune-4 153MB/s ± 2% 215MB/s ± 2% +40.96% (p=0.000 n=20+20) Change-Id: Ic15f6e2d6e56a3d15c74f56159e2eae020ba73ba Reviewed-on: https://go-review.googlesource.com/28816Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Change-Id: I9ed62e8a6d8b9204c18748efd7845adabf3460b9 Reviewed-on: https://go-review.googlesource.com/28775 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
When arg length is wrong, op is not set, so it always prints "should have 0 args". Change-Id: If7bcb41d993919d0038d2a09e16188c79dfbd858 Reviewed-on: https://go-review.googlesource.com/28831Reviewed-by: Keith Randall <khr@golang.org>
-
Michal Bohuslávek authored
Change-Id: I003795d8dc2176532ee133740bf35e23a3aa3878 Reviewed-on: https://go-review.googlesource.com/28811Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
Before this CL the runtime prevented printing of overlong strings with the print function when the length of the string was determined to be corrupted. Corruption was checked by comparing the string size against the limit which was stored in maxstring. However maxstring was not updated everywhere were go strings were created e.g. for string constants during compile time. Thereby the check for maximum string length prevented the printing of some valid strings. The protection maxstring provided did not warrant the bookkeeping and global synchronization needed to keep maxstring updated to the correct limit everywhere. Fixes #16999 Change-Id: I62cc2f4362f333f75b77f199ce1a71aac0ff7aeb Reviewed-on: https://go-review.googlesource.com/28813Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Fixes #14196 Change-Id: Ife7950289ac6adbcfc4d0f2fce31f20bc2657858 Reviewed-on: https://go-review.googlesource.com/28772Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-