- 29 Feb, 2016 7 commits
-
-
Ian Lance Taylor authored
Update #14559. Change-Id: I8894f8e16902685f55a21d902199fbe0905f0558 Reviewed-on: https://go-review.googlesource.com/20050 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Brad Fitzpatrick authored
Named returned values should only be used on public funcs and methods when it contributes to the documentation. Named return values should not be used if they're only saving the programmer a few lines of code inside the body of the function, especially if that means there's stutter in the documentation or it was only there so the programmer could use a naked return statement. (Naked returns should not be used except in very small functions) This change is a manual audit & cleanup of public func signatures. Signatures were not changed if: * the func was private (wouldn't be in public godoc) * the documentation referenced it * the named return value was an interesting name. (i.e. it wasn't simply stutter, repeating the name of the type) There should be no changes in behavior. (At least: none intended) Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109 Reviewed-on: https://go-review.googlesource.com/20024 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Shenghou Ma authored
Fixes #14557. Change-Id: I9610b79aafe9c15f9c998739b586fd0b41b90d70 Reviewed-on: https://go-review.googlesource.com/20031Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Mostly renaming variables for clarity. Passes toolstash -cmp. Change-Id: I9867137c34c14985cbbbdb2d34fbbe4cc65cb6fb Reviewed-on: https://go-review.googlesource.com/20023Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Passes toolstash -cmp. Casual timings show about a 3% improvement in compile times. Update #14473. Change-Id: I584add2e8f1a52486ba418b25ba6122b7347b643 Reviewed-on: https://go-review.googlesource.com/19989Reviewed-by:
-
Martin Möhrmann authored
Do not replace the sign in front of a number with a space if both f.space and f.plus are both specified for number formatting. This was already the case for integers but not for floats and complex numbers. Updates: #14543. Change-Id: I07ddeb505003db84a8a7d2c743dc19fc427a00bd Reviewed-on: https://go-review.googlesource.com/19974 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
Besides being more efficient in a large build, this avoids a possible race when creating the input file. Change-Id: Ifc2cb055925a76be9c90eac56d84ebd9e14f2bbc Reviewed-on: https://go-review.googlesource.com/19392Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
- 28 Feb, 2016 10 commits
-
-
Tamir Duberstein authored
This is minor cleanup that reduces test output noise. Change-Id: Ib6db4daf8cb67b7784b2d5b222fa37c7f78a6a04 Reviewed-on: https://go-review.googlesource.com/19997Reviewed-by:
-
Tamir Duberstein authored
This is minor cleanup that makes the tests more readable. Change-Id: I9f1f98f0f035096c284bdf3501e7520517a3e4d9 Reviewed-on: https://go-review.googlesource.com/19993Reviewed-by:
-
Justin Nuß authored
Found this while reading through the code. The benchmark accidently called the wrong function. Change-Id: Idb88aa71e7098a4e29e7f5f39e64f8c5f8936a2a Reviewed-on: https://go-review.googlesource.com/19977Reviewed-by:
-
Joe Tsai authored
Motivation: * Previously, the size of the compressed data was used for metrics, rather than the uncompressed size. This causes the library to appear to perform poorly relative to C or other implementation. Switch it to use the uncompressed size so that it matches how decompression benchmarks are usually done (like in compress/flate). This also makes it easier to compare bzip2 rates to other algorithms since they measure performance in this way. * Also, reset the timer after doing initialization work. Change-Id: I32112c2ee8e7391e658c9cf31039f70a689d9b9d Reviewed-on: https://go-review.googlesource.com/17611Reviewed-by:
-
Joe Tsai authored
The bzip2 block size is a multiple of 100*1000 not 100*1024. Thus, the bzip2 decoder would incorrectly decode files with larger block sizes when it should have otherwise failed. Fortunately, we can correct this in a backwards compatible way since Go has no implementation of a bzip2 encoder to produce bad blocks :) To confirm that the C bzip2 utlity chokes on this data: $ echo "425a683131415926535936dc55330063ffc0006000200020a40830008b00 08b8bb9229c28481b6e2a998" | xxd -r -p | bzip2 -d bzip2: Data integrity error when decompressing. Fixes #13941 Change-Id: I2402e8829a8027ef94dd4fac050b200440a3d4e4 Reviewed-on: https://go-review.googlesource.com/20011 Run-TryBot: Joe Tsai <joetsai@digital-static.net> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joe Tsai authored
The LZ77 portion of DEFLATE is relatively self-contained. For the decompression side of things, we extract this logic out for the following reasons: * It is easier to test just the LZ77 portion of the logic. * It reduces the noise in the inflate.go Also, we adjust the way that callbacks are handled in the inflate. Instead of using functions to abstract the logical componets of huffmanBlock(), use goto statements to jump between the necessary sections. This is faster since it avoids a function call and is arguably more readable. benchmark old MB/s new MB/s speedup BenchmarkDecodeDigitsSpeed1e4-4 53.62 60.11 1.12x BenchmarkDecodeDigitsSpeed1e5-4 61.90 69.07 1.12x BenchmarkDecodeDigitsSpeed1e6-4 63.24 70.58 1.12x BenchmarkDecodeDigitsDefault1e4-4 54.10 59.00 1.09x BenchmarkDecodeDigitsDefault1e5-4 69.50 74.07 1.07x BenchmarkDecodeDigitsDefault1e6-4 71.54 75.85 1.06x BenchmarkDecodeDigitsCompress1e4-4 54.39 58.94 1.08x BenchmarkDecodeDigitsCompress1e5-4 69.21 73.96 1.07x BenchmarkDecodeDigitsCompress1e6-4 71.14 75.75 1.06x BenchmarkDecodeTwainSpeed1e4-4 53.15 58.13 1.09x BenchmarkDecodeTwainSpeed1e5-4 66.56 72.29 1.09x BenchmarkDecodeTwainSpeed1e6-4 69.13 75.11 1.09x BenchmarkDecodeTwainDefault1e4-4 56.00 60.23 1.08x BenchmarkDecodeTwainDefault1e5-4 77.84 82.27 1.06x BenchmarkDecodeTwainDefault1e6-4 82.07 86.85 1.06x BenchmarkDecodeTwainCompress1e4-4 56.13 60.38 1.08x BenchmarkDecodeTwainCompress1e5-4 78.23 82.62 1.06x BenchmarkDecodeTwainCompress1e6-4 82.38 86.73 1.05x Change-Id: I8c6ae0e6bed652dd0570fc113c999977f5e71636 Reviewed-on: https://go-review.googlesource.com/16528Reviewed-by:
-
Caio Marcelo de Oliveira Filho authored
Moves the implementation of RunBenchmarks to a non-exported function that returns whether the execution was OK, and uses that to identify failure in benchmarks.The exported function is kept for compatibility. Like before, benchmarks will only be executed if tests and examples pass. The PASS message will not be printed if there was a failure in a benchmark. Example output BenchmarkThatCallsFatal-8 --- FAIL: BenchmarkThatCallsFatal-8 x_test.go:6: called by benchmark FAIL exit status 1 FAIL _/.../src/cmd/go/testdata/src/benchfatal 0.009s Fixes #14307. Change-Id: I6f3ddadc7da8a250763168cc099ae8b325a79602 Reviewed-on: https://go-review.googlesource.com/19889Reviewed-by:
-
Ian Lance Taylor authored
When Go code is used with C code compiled with -fsanitize=thread, adds thread sanitizer calls so that correctly synchronized Go code does not cause spurious failure reports from the thread sanitizer. This may cause some false negatives, but for the thread sanitizer what is most important is avoiding false positives. Change-Id: If670e4a6f2874c7a2be2ff7db8728c6036340a52 Reviewed-on: https://go-review.googlesource.com/17421Reviewed-by:
-
kortschak authored
Change-Id: If03185a21e088c9b383a82c14d649805f00c8042 Reviewed-on: https://go-review.googlesource.com/20000Reviewed-by:
Minux Ma <minux@golang.org>
-
Austin Clements authored
Commit a5c3bbe0 modified adjustpointers to use *uintptrs instead of *unsafe.Pointers for manipulating stack pointers for clarity and to eliminate the unnecessary write barrier when writing the updated stack pointer. This commit makes the equivalent change to adjustpointer. Change-Id: I6dc309590b298bdd86ecdc9737db848d6786c3f7 Reviewed-on: https://go-review.googlesource.com/17148Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 27 Feb, 2016 11 commits
-
-
Ian Lance Taylor authored
Fixes #14483. Change-Id: I0cddfe27fd8d00ba85659d0b618410e39ebf45cb Reviewed-on: https://go-review.googlesource.com/19860Reviewed-by:
-
Ian Lance Taylor authored
Update #14473. Change-Id: Iba1ecf42d9ab5a93144941439d5cc6b0b4f4a3ac Reviewed-on: https://go-review.googlesource.com/19992Reviewed-by:
-
Martin Möhrmann authored
Once upon a time fmt did use bytes.Buffer for its buffer. The buffer write methods still mimic the bytes.Buffer signatures. The current code depends on manipulating the buffer []bytes array directly which makes going back to bytes.Buffer by only changing the type of buffer impossible. Since type buffer is not exported the methods can be simplified to the needs of fmt. This saves space and avoids unnecessary overhead. Use WriteString instead of Write for known inputs since WriteString is faster than Write to append the same data. This also saves space in the binary. Remove the add method from Printer and depending on the data to be written use WriteRune or WriteByte directly instead. In total makes the go binary around 4 kilobyte smaller. name old time/op new time/op delta SprintfEmpty-2 24.1ns ± 3% 23.8ns ± 1% -1.14% (p=0.000 n=20+20) SprintfString-2 114ns ± 2% 114ns ± 4% ~ (p=0.558 n=20+19) SprintfInt-2 116ns ± 9% 118ns ± 7% ~ (p=0.086 n=20+20) SprintfIntInt-2 195ns ± 6% 193ns ± 5% ~ (p=0.345 n=20+19) SprintfPrefixedInt-2 251ns ±16% 241ns ± 9% -3.69% (p=0.024 n=20+19) SprintfFloat-2 203ns ± 4% 205ns ± 5% ~ (p=0.153 n=20+20) SprintfBoolean-2 101ns ± 7% 96ns ±11% -5.23% (p=0.005 n=19+20) ManyArgs-2 651ns ± 7% 628ns ± 7% -3.44% (p=0.002 n=20+20) FprintInt-2 164ns ± 2% 158ns ± 2% -3.62% (p=0.000 n=20+18) FprintfBytes-2 215ns ± 1% 216ns ± 1% +0.58% (p=0.000 n=20+20) FprintIntNoAlloc-2 115ns ± 0% 112ns ± 0% -2.61% (p=0.000 n=20+20) ScanInts-2 700µs ± 0% 702µs ± 1% +0.38% (p=0.000 n=18+20) ScanRecursiveInt-2 82.7ms ± 0% 82.7ms ± 0% ~ (p=0.820 n=20+20) Change-Id: I0409eb170b8a26d9f4eb271f6292e5d39faf2d8b Reviewed-on: https://go-review.googlesource.com/19955Reviewed-by:
-
Justin Nuß authored
The current implementations of the AppendQuote functions use quoteWith (through Quote) for quoting the given value and appends the returned string to the dst byte slice. quoteWith internally creates a byte slice on each call which gets converted to a string in Quote. This means the AppendQuote functions always allocates a new byte slice and a string only to append them to an existing byte slice. In the case of (Append)QuoteRune the string passed to quoteWith will also needs to be allocated from a rune first. Split quoteWith into two functions (quoteWith and appendQuotedWith) and replace the call to Quote inside AppendQuote with appendQuotedWith, which appends directly to the byte slice passed to AppendQuote and also avoids the []byte->string conversion. Also introduce the 2 functions quoteRuneWith and appendQuotedRuneWith that work the same way as quoteWith and appendQuotedWith, but take a single rune instead of a string, to avoid allocating a new string when appending a single rune, and use them in (Append)QuoteRune. Also update the ToASCII and ToGraphic variants to use the new functions. Benchmark results: benchmark old ns/op new ns/op delta BenchmarkQuote-8 428 503 +17.52% BenchmarkQuoteRune-8 148 105 -29.05% BenchmarkAppendQuote-8 435 307 -29.43% BenchmarkAppendQuoteRune-8 158 23.5 -85.13% benchmark old allocs new allocs delta BenchmarkQuote-8 3 3 +0.00% BenchmarkQuoteRune-8 3 2 -33.33% BenchmarkAppendQuote-8 3 0 -100.00% BenchmarkAppendQuoteRune-8 3 0 -100.00% benchmark old bytes new bytes delta BenchmarkQuote-8 144 144 +0.00% BenchmarkQuoteRune-8 16 16 +0.00% BenchmarkAppendQuote-8 144 0 -100.00% BenchmarkAppendQuoteRune-8 16 0 -100.00% Change-Id: I77c148d5c7242f1b0edbbeeea184878abb51a522 Reviewed-on: https://go-review.googlesource.com/18962 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Mikio Hara authored
This is a followup change to #13111 for filtering out IPv6 literals and absolute FQDNs from being as the SNI values. Updates #13111. Fixes #14404. Change-Id: I09ab8d2a9153d9a92147e57ca141f2e97ddcef6e Reviewed-on: https://go-review.googlesource.com/19704Reviewed-by:
-
Martin Möhrmann authored
Move the decision if zero padding is allowed to doPrintf where the other formatting decisions are made. Removes some dead code for negative f.wid that was never used due to f.wid always being positive and f.minus deciding if left or right padding should be used. New padding code writes directly into the buffer and is as fast as the old version but avoids the cost of needing package init. name old time/op new time/op delta SprintfPadding-2 246ns ± 5% 245ns ± 4% ~ (p=0.345 n=50+47) Change-Id: I7dfddbac8e328f4ef0cdee8fafc0d06c784b2711 Reviewed-on: https://go-review.googlesource.com/19957 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Accidentally added in https://golang.org/cl/19968. Change-Id: Id70917c4d1f69db149688d797c90a19557d16f72 Reviewed-on: https://go-review.googlesource.com/19985Reviewed-by:
-
David du Colombier authored
Plan 9 doesn't define main, so the INITENTRY symbol remains with the SXREF type, which leads Entryvalue to fail on "entry not text: main". Fixes #14536. Change-Id: Id9b7d61e5c2202aba3ec9cd52f5b56e0a38f7c47 Reviewed-on: https://go-review.googlesource.com/19973 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Change-Id: I6ac3d11ee8896f636235fe10c2556f93584019b5 Reviewed-on: https://go-review.googlesource.com/19984Reviewed-by:
-
Matthew Dempsky authored
Split the syms array into separate basicTypes and builtinFuncs arrays. Also, in lexfini, instead of duplicating the code from lexinit to declare the builtin identifiers in the user package, just import them from builtinpkg like how importdot works. Change-Id: Ic3b3b454627a46f7bd5f290d0e31443e659d431f Reviewed-on: https://go-review.googlesource.com/19936 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
Introduces a new types Nodes that can be used to replace NodeList. Update #14473. Change-Id: Id77c5dcae0cbeb898ba12dd46bd400aad408871c Reviewed-on: https://go-review.googlesource.com/19969Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
- 26 Feb, 2016 12 commits
-
-
Martin Möhrmann authored
All io.Reader that are passed to newScanState in all the standard library tests that implement io.RuneReader also implement io.RuneScanner. Do not check on each call ScanState's UnreadRune that the used RuneReader also implements the UnreadRune method by using a private interface. Instead require the used Reader to implement the public RuneScanner interface. The extra implementation logic for UnreadRune is removed from ScanState. Instead the readRune wrapper is extended to implement UnreadRune for the RuneScanner interface. If the Reader passed to newScanstate does not implement RuneScanner the readRune wrapper is used to implement the missing functionality. Note that a RuneReader that does not implement RuneScanner will also be wrapped by runeRead which was not the case before. Performance with the readRune wrapper is better than without before. Add benchmark to compare performance with and without using the readRune wrapper. name old time/op new time/op delta ScanInts-2 704µs ± 0% 615µs ± 1% -12.73% (p=0.000 n=20+20) ScanRecursiveInt-2 82.6ms ± 0% 51.4ms ± 0% -37.71% (p=0.000 n=20+20) ScanRecursiveIntReaderWrapper-2 85.1ms ± 0% 52.4ms ± 0% -38.36% (p=0.000 n=20+20) Change-Id: I8c6e85db9b87a8171caab12f020b6e256b498e81 Reviewed-on: https://go-review.googlesource.com/19895 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Pull all alg-related code into its own file. subr.go is a Hobbesian Leviathan. 100% code movement. Cleanup and improvements to follow. Change-Id: Ib9c8f66563fdda90c6e8cf646d366a9487a4648d Reviewed-on: https://go-review.googlesource.com/19980Reviewed-by:
Dave Cheney <dave@cheney.net> Run-TryBot: Dave Cheney <dave@cheney.net> Reviewed-by:
-
Matthew Dempsky authored
While here, merge LINC and LDEC into LINCOP. Fixes #13244. Change-Id: I8ea426f986d60d35c3b1a80c056a7aa49d22d802 Reviewed-on: https://go-review.googlesource.com/19928Reviewed-by:
-
Ian Lance Taylor authored
Save a few bytes in Func. Passes toolstash -cmp. Update #14473. Change-Id: I824fa7d5cb2d93f6f59938ccd86114abcbea0043 Reviewed-on: https://go-review.googlesource.com/19968Reviewed-by:
-
Ian Lance Taylor authored
Passes toolstash -cmp. Update #14473. Change-Id: I7285175b1992a29033fdc9e81d6f30545e5cc30d Reviewed-on: https://go-review.googlesource.com/19967Reviewed-by:
-
Josh Bleecher Snyder authored
The old implementation assumed that all memory runs were terminated by non-memory fields. This isn't necessarily so. They might be terminated by padding or blank fields. For example, given type T struct { a int64 b byte c, d, e int64 } the old implementation did a memory comparison on a+b, on c, and on d+e. Instead, check for memory runs at the beginning of every round. This now generates a memory comparison on a+b and on c+d+e. Also, delete some now-dead code. Change-Id: I66bffb111420adf6919bd708e4fb3a1e1f07fadd Reviewed-on: https://go-review.googlesource.com/19841Reviewed-by: -
Josh Bleecher Snyder authored
Passes toolstash -cmp. Change-Id: Ifae69e5ba673f01da3dfc1fd30cdc51873481623 Reviewed-on: https://go-review.googlesource.com/19840Reviewed-by:
-
Robert Griesemer authored
By using a Pragma bit set (8 bits) rather than 8 booleans, also reduce Func type size by 8 bytes (208B -> 200B on 64bit platforms, 116B -> 108B on 32bit platforms). Change-Id: Ibb7e1f8c418a0b5bc6ff813cbdde7bc6f0013b5a Reviewed-on: https://go-review.googlesource.com/19966Reviewed-by:
-
Matthew Dempsky authored
Instead add a dedicated keywords map for use in lexer.ident and drop Sym's Lexical field. Change-Id: Ia668e65499035ff7167fabbbd0cd027102b21231 Reviewed-on: https://go-review.googlesource.com/19935Reviewed-by:
-
Matthew Dempsky authored
If a general comment contains multiple newline characters, we can't simply unread one and then re-lex it via the general whitespace lexing phase, because then we'll reset lineno to the line before the "*/" marker, rather than keeping it where we found the "/*" marker. Also, for processing imports, call importfile before advancing the lexer with p.next(), so that lineno reflects the line where we found the import path, and not the token afterwards. Fixes #14520. Change-Id: I785a2d83d632280113d4b757de0d57c88ba2caf4 Reviewed-on: https://go-review.googlesource.com/19934Reviewed-by:
-
Ian Lance Taylor authored
The new TestDashS was leaving a dreg "test" file in cmd/compile/internal/gc. Create it in the temporary directory instead. Also change path.Join to filepath.Join throughout global_test.go. Change-Id: Ib7707fada2b3ab5e8abc2ba74e4c402821c1408b Reviewed-on: https://go-review.googlesource.com/19965 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
A slice uses less memory than a NodeList, and has better memory locality when walking the list. This uncovered a tricky case involving closures: the escape analysis pass when run on a closure was appending to the Dcl list of the OCLOSURE rather than the ODCLFUNC. This happened to work because they shared the same NodeList. Fixed with a change to addrescapes, and a check to Tempname to catch any recurrences. This removes the last use of the listsort function outside of tests. I'll send a separate CL to remove it. Unfortunately, while this passes all tests, it does not pass toolstash -cmp. The problem is that cmpstackvarlt does not fully determine the sort order, and the change from listsort to sort.Sort, while generally desirable, produces a different ordering. I could stage this by first making cmpstackvarlt fully determined, but no matter what toolstash -cmp is going to break at some point. In my casual testing the compiler is 2.2% faster. Update #14473. Change-Id: I367d66daa4ec73ed95c14c66ccda3a2133ad95d5 Reviewed-on: https://go-review.googlesource.com/19919Reviewed-by:
-
