- 05 Oct, 2016 26 commits
-
-
Joe Tsai authored
This reverts commit 59320c39. Reasons: This CL was causing failures on a large regression test that we run within Google. The issues arises from two bugs in the CL: * The CL dropped support for ';' as a delimiter (see https://golang.org/issue/2210) * The handling of an empty string caused an empty record to be added when no record was added (see https://golang.org/cl/30454 for my attempted fix) The logic being added is essentially a variation of url.ParseQuery, but altered to accept an io.Reader instead of a string. Since it is duplicated (but modified) logic, there needs to be good tests to ensure that it's implementation doesn't drift in functionality from url.ParseQuery. Fixing the above issues and adding the associated regression tests leads to >100 lines of codes. For a 4% reduction in CPU time, I think this complexity and duplicated logic is not worth the effort. As such, I am abandoning my efforts to fix the existing issues and believe that reverting CL/20301 is the better course of action. Updates #14655 Change-Id: Ibb5be0a5b48a16c46337e213b79467fcafee69df Reviewed-on: https://go-review.googlesource.com/30470 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alexander Döring authored
Updates #16360 Change-Id: I0e0afe7a89f2ebcb3e5bbc345f77a605d3afc398 Reviewed-on: https://go-review.googlesource.com/30103Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jirka Daněk authored
The UnmarshalTypeError has two new fields Struct and Field, used when constructing the error message. Fixes #6716. Change-Id: I67da171480a9491960b3ae81893770644180f848 Reviewed-on: https://go-review.googlesource.com/18692 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Quentin Smith authored
Fixes #17224. Some systems have more than just "lo" in a fresh network namespace, due to IPv6. Instead of testing for exactly 3 lines of output (implying 1 interface), just test to make sure that the unshare call resulted in fewer interfaces than before. This should still verify that unshare did something. Change-Id: Iaf84c2b0e673fc207059d62e2f4dd7583a753419 Reviewed-on: https://go-review.googlesource.com/30372Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jessica Frazelle <me@jessfraz.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Change float32/float64 formatting to use non-exponential form for a slightly wider range, to more closely match ES6 JSON.stringify and other JSON generators. Most notably: 1e20 now formats as 100000000000000000000 (previously 1e+20) 1e-6 now formats as 0.000001 (previously 1e-06) 1e-7 now formats as 1e-7 (previously 1e-07) This also brings the int64 and float64 formatting in line with each other, for all shared representable values. For example both int64(1234567) and float64(1234567) now format as "1234567", where before the float64 formatted as "1.234567e+06". The only variation now compared to ES6 JSON.stringify is that Go continues to encode negative zero as "-0", not "0", so that the value continues to be preserved during JSON round trips. Fixes #6384. Fixes #14135. Change-Id: Ib0e0e009cd9181d75edc0424a28fe776bcc5bbf8 Reviewed-on: https://go-review.googlesource.com/30371Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
These are conditional branches that takes a register instead of flags as control value. Reduce binary size by 0.7%, text size by 2.4% (cmd/go as an exmaple). Change-Id: I0020cfde745f9eab680b8b949ad28c87fe183afd Reviewed-on: https://go-review.googlesource.com/30030Reviewed-by: David Chase <drchase@google.com>
-
Cherry Zhang authored
In the function prologue, we emit a jump to the beginning of the function immediately after calling morestack. And in the runtime stack growing code, it decodes and emulates that jump. This emulation was necessary before we had per-PC SP deltas, since the traceback code assumed that the frame size was fixed for the whole function, except on the first instruction where it was 0. Since we now have per-PC SP deltas and PCDATA, we can correctly record that the frame size is 0. This makes the emulation unnecessary. This may be helpful for registerized calling convention, where there may be unspills of arguments after calling morestack. It also simplifies the runtime. Change-Id: I7ebee31eaee81795445b33f521ab6a79624c4ceb Reviewed-on: https://go-review.googlesource.com/30138Reviewed-by: David Chase <drchase@google.com>
-
Yasuhiro Matsumoto authored
Windows doesn't remove an open file. Fixes #17345 Change-Id: I283930c7d6eb3bc09ad208191afefe989804ce32 Reviewed-on: https://go-review.googlesource.com/30430 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Lynn Boger authored
This change updates PPC64.rules to recognize constant shift counts and generate more efficient code sequences in those cases. Fixes #17336 Change-Id: I8a7b812408d7a68388df41e42bad045dd214be17 Reviewed-on: https://go-review.googlesource.com/30310 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Matthew Dempsky authored
complex64 and complex128 are treated like [2]float32 and [2]float64, so it makes sense to align them the same way. Change-Id: Ic614bcdcc91b080aeb1ad1fed6fc15ba5a2971f8 Reviewed-on: https://go-review.googlesource.com/19800 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Keith Randall authored
To refine a set of possibly equivalent values, the old CSE algorithm picked one value, compared it against all the others, and made two sets out of the results (the values that match the picked value and the values that didn't). Unfortunately, this leads to O(n^2) behavior. The picked value ends up being equal to no other values, we make size 1 and size n-1 sets, and then recurse on the size n-1 set. Instead, sort the set by the equivalence classes of its arguments. Then we just look for spots in the sorted list where the equivalence classes of the arguments change. This lets us do a multi-way split for O(n lg n) time. This change makes cmpDepth unnecessary. The refinement portion used to call the type comparator. That is unnecessary as the type was already part of the initial partition. Lowers time of 16361 from 8 sec to 3 sec. Lowers time of 15112 from 282 sec to 20 sec. That's kind of unfair, as CL 30257 changed it from 21 sec to 282 sec. But that CL fixed other bad compile times (issue #17127) by large factors, so net still a big win. Fixes #15112 Fixes #16361 Change-Id: I351ce111bae446608968c6d48710eeb6a3d8e527 Reviewed-on: https://go-review.googlesource.com/30354Reviewed-by: Todd Neal <todd@tneal.org>
-
Justin Nuß authored
This commit changes parseRecord to allocate a single string per record, instead of per field, by using indexes into the raw record. Benchstat (done with f69991c1) name old time/op new time/op delta Read-8 3.17µs ± 0% 2.78µs ± 1% -12.35% (p=0.016 n=4+5) ReadWithFieldsPerRecord-8 3.18µs ± 1% 2.79µs ± 1% -12.23% (p=0.008 n=5+5) ReadWithoutFieldsPerRecord-8 4.59µs ± 0% 2.77µs ± 0% -39.58% (p=0.016 n=4+5) ReadLargeFields-8 57.0µs ± 0% 55.7µs ± 0% -2.18% (p=0.008 n=5+5) name old alloc/op new alloc/op delta Read-8 660B ± 0% 664B ± 0% +0.61% (p=0.008 n=5+5) ReadWithFieldsPerRecord-8 660B ± 0% 664B ± 0% +0.61% (p=0.008 n=5+5) ReadWithoutFieldsPerRecord-8 1.14kB ± 0% 0.66kB ± 0% -41.75% (p=0.008 n=5+5) ReadLargeFields-8 3.86kB ± 0% 3.94kB ± 0% +1.86% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Read-8 30.0 ± 0% 18.0 ± 0% -40.00% (p=0.008 n=5+5) ReadWithFieldsPerRecord-8 30.0 ± 0% 18.0 ± 0% -40.00% (p=0.008 n=5+5) ReadWithoutFieldsPerRecord-8 50.0 ± 0% 18.0 ± 0% -64.00% (p=0.008 n=5+5) ReadLargeFields-8 66.0 ± 0% 24.0 ± 0% -63.64% (p=0.008 n=5+5) For a simple application that I wrote, which reads in a CSV file (via ReadAll) and outputs the number of rows read (15857625 rows), this change reduces the total time on my notebook from ~58 seconds to ~48 seconds. This reduces time and allocations (bytes) each by ~6% for a real world CSV file at work (~230000 rows, 13 colums). Updates #16791 Change-Id: Ia07177c94624e55cdd3064a7d2751fb69322d3e4 Reviewed-on: https://go-review.googlesource.com/24723Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
plive.go (except for printeffects and livenessprintblock) and reflect.go changes were prepared mechanically with gofmt -r. Passes toolstash. name old alloc/op new alloc/op delta Template 44.3MB ± 0% 44.3MB ± 0% ~ (p=0.367 n=30+30) Unicode 37.4MB ± 0% 37.4MB ± 0% ~ (p=0.665 n=30+30) GoTypes 125MB ± 0% 125MB ± 0% ~ (p=0.067 n=30+30) Compiler 515MB ± 0% 515MB ± 0% ~ (p=0.542 n=30+28) name old allocs/op new allocs/op delta Template 434k ± 0% 434k ± 0% ~ (p=0.076 n=30+29) Unicode 367k ± 0% 367k ± 0% ~ (p=0.716 n=29+30) GoTypes 1.24M ± 0% 1.24M ± 0% ~ (p=0.428 n=29+29) Compiler 4.47M ± 0% 4.47M ± 0% ~ (p=0.225 n=28+30) Change-Id: Ibaf0668567b3f69fba06aa03b7997c8fb152113a Reviewed-on: https://go-review.googlesource.com/30356 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Fraenkel authored
Always close the file regardless of whether the copy succeeds or fails. Pass along the close error if the copy succeeds Fixes #16296 Change-Id: Ib394655b91d25750f029f17b3846d985f673fb50 Reviewed-on: https://go-review.googlesource.com/30410Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
It already implemented the Timeout method, but implementing the full net.Error is more convenient. Fixes #14238 (again). Change-Id: Ia87f897f0f35bcb49865e2355964049227951ca6 Reviewed-on: https://go-review.googlesource.com/30370 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
Also adds two tests: one to exercise the counter incrementing code and one which checks the output of the optimized implementation against that of the generic implementation for large/unaligned data sizes. Uses the KIMD instruction for GHASH and the KMCTR instruction for AES in counter mode. AESGCMSeal1K 75.0MB/s ± 2% 1008.7MB/s ± 1% +1245.71% (p=0.000 n=10+10) AESGCMOpen1K 75.3MB/s ± 1% 1006.0MB/s ± 1% +1235.59% (p=0.000 n=10+9) AESGCMSeal8K 78.5MB/s ± 1% 1748.4MB/s ± 1% +2127.34% (p=0.000 n=9+10) AESGCMOpen8K 78.5MB/s ± 0% 1752.7MB/s ± 0% +2134.07% (p=0.000 n=10+9) Change-Id: I88dbcfcb5988104bfd290ae15a60a2721c1338be Reviewed-on: https://go-review.googlesource.com/30361Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Should fix the clang builder. Change-Id: I3ee34581b6a7ec902420de72a8a08a2426997782 Reviewed-on: https://go-review.googlesource.com/30363 Run-TryBot: Michael Munday <munday@ca.ibm.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I9783d8023d453a72c4605a308064bef98168bcb8 Reviewed-on: https://go-review.googlesource.com/30360Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Aliaksandr Valialkin authored
Fixes #17006 Change-Id: I3c2060ca5384a4b9782a7d804305d2cf4388dd5a Reviewed-on: https://go-review.googlesource.com/29014 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
Calling cgocallback from a signal handler can fail when using the race detector. Calling cgocallback will lead to a call to newextram which will call oneNewExtraM which will call racegostart. The racegostart function will set up some race detector data structures, and doing that will sometimes call the C memory allocator. If we are running the signal handler from a signal that interrupted the C memory allocator, we will crash or hang. Instead, change the signal handler code to call needm and dropm. The needm function will grab allocated m and g structures and initialize the g to use the current stack--the signal stack. That is all we need to safely call code that allocates memory and checks whether it needs to split the stack. This may temporarily leave us with no m available to run a cgo callback, but that is OK in this case since the code we call will quickly either crash or call dropm to return the m. Implementing this required changing some of the setSignalstackSP functions to avoid a write barrier. These functions never need a write barrier but in some cases generated one anyhow because on some systems the ss_sp field is a pointer. Change-Id: I3893f47c3a66278f85eab7f94c1ab11d4f3be133 Reviewed-on: https://go-review.googlesource.com/30218 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Ian Lance Taylor authored
Change-Id: I56de359a5ccdc0a10925cd372fa86534353c6ca0 Reviewed-on: https://go-review.googlesource.com/30358 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Benchmarks broken off from https://golang.org/cl/24723 and modified to allocate less in the places we're not trying to measure. Updates #16791 Change-Id: I508e4cfeac60322d56f1d71ff1912f6a6f183a63 Reviewed-on: https://go-review.googlesource.com/30357 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jeff R. Allen authored
All the prefixes of the testGIF produce errors today, but they differ wildly in which errors: some are io.EOF, others are io.ErrUnexpectedEOF, and others are gif-specific. Make them all gif-specific to explain context, and make any complaining about EOF be sure to mention the EOF is unexpected. Fixes #11390. Change-Id: I742c39c88591649276268327ea314e68d1de1845 Reviewed-on: https://go-review.googlesource.com/17493 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #11441. Test tables generated by package main import ( "bytes" "fmt" "log" "os/exec" "strconv" "strings" ) var inputs = []float64{ 0.5, 1.5, 2.5, 3.5, -0.5, -1.5, -2.5, -3.5, 0.1, 0.01, 1e-8, 1e-16, 1e-3, 1e-16, 1e-308, 5.6e-309, 5.5e-309, 1e-309, 1e-323, 5e-324, -0.1, -0.01, -1e-8, -1e-16, -1e-3, -1e-16, -1e-308, -5.6e-309, -5.5e-309, -1e-300 / 1e9, -1e-300 / 1e23, -5e-300 / 1e24, -0.9999999999999999, -1.0000000000000002, -1.9999999999999998, -2.0000000000000004, -100.00000000000001, -99.999999999999986, 17, 171, 171.6, 171.624, 171.625, 172, 2000, -100.5, -160.5, -170.5, -171.5, -176.5, -177.5, -178.5, -179.5, -201.0001, -202.9999, -1000.5, -1000000000.3, -4503599627370495.5, -63.349078729022985, -127.45117632943295, } func main() { var buf bytes.Buffer for _, v := range inputs { fmt.Fprintf(&buf, "gamma(%.1000g)\n", v) } cmd := exec.Command("gp", "-q") cmd.Stdin = &buf out, err := cmd.CombinedOutput() if err != nil { log.Fatalf("gp: %v", err) } f := strings.Split(string(out), "\n") if len(f) > 0 && f[len(f)-1] == "" { f = f[:len(f)-1] } if len(f) != len(inputs) { log.Fatalf("gp: wrong output count\n%s\n", out) } for i, g := range f { gf, err := strconv.ParseFloat(strings.Replace(g, " E", "e", -1), 64) if err != nil { if strings.Contains(err.Error(), "value out of range") { if strings.HasPrefix(g, "-") { fmt.Printf("\t{%g, Inf(-1)},\n", inputs[i]) } else { fmt.Printf("\t{%g, Inf(1)},\n", inputs[i]) } continue } log.Fatal(err) } if gf == 0 && strings.HasPrefix(g, "-") { fmt.Printf("\t{%g, Copysign(0, -1)},\n", inputs[i]) continue } fmt.Printf("\t{%g, %g},\n", inputs[i], gf) } } Change-Id: Ie98c7751d92b8ffb40e8313f5ea10df0890e2feb Reviewed-on: https://go-review.googlesource.com/30146 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org>
-
Russ Cox authored
The 387 implementation is less accurate and slower. name old time/op new time/op delta Exp-8 29.7ns ± 2% 24.0ns ± 2% -19.08% (p=0.000 n=10+10) This makes Gamma more accurate too. Change-Id: Iad33b9cce0b087ccbce3e08ba7a6d285c4999d02 Reviewed-on: https://go-review.googlesource.com/30230 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
The documentation for doc says: > Doc prints the documentation comments associated with the item identified by its > arguments (a package, const, func, type, var, or method) followed by a one-line > summary of each of the first-level items "under" that item (package-level > declarations for a package, methods for a type, etc.). Certain variables (and constants, functions, and types) have value specifications that are multiple lines long. Prior to this change, doc would print out all of the lines necessary to display the value. This is inconsistent with the documented behavior, which guarantees a one-line summary for all first-level items. We fix this here by writing a general oneLineNode method that always returns a one-line summary (guaranteed!) of any input node. Packages like image/color/palette and unicode now become much more readable since large slices are now a single line. $ go doc image/color/palette <<< // Before: var Plan9 = []color.Color{ color.RGBA{0x00, 0x00, 0x00, 0xff}, color.RGBA{0x00, 0x00, 0x44, 0xff}, color.RGBA{0x00, 0x00, 0x88, 0xff}, ... // Hundreds of more lines! } var WebSafe = []color.Color{ color.RGBA{0x00, 0x00, 0x00, 0xff}, color.RGBA{0x00, 0x00, 0x33, 0xff}, color.RGBA{0x00, 0x00, 0x66, 0xff}, ... // Hundreds of more lines! } // After: var Plan9 = []color.Color{ ... } var WebSafe = []color.Color{ ... } >>> In order to test this, I ran `go doc` and `go doc -u` on all of the standard library packages and diff'd the output with and without the change to ensure that all differences were intended. Fixes #13072 Change-Id: Ida10b7796b7e4e174a929b55c60813a9eb7158fe Reviewed-on: https://go-review.googlesource.com/25420 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
- 04 Oct, 2016 14 commits
-
-
Kevin Burke authored
Change-Id: I3f13488605ab62eba5d3c59d5e9df1bcf69dd571 Reviewed-on: https://go-review.googlesource.com/30355Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
For #16339 Change-Id: I8927f40e0fd166795f41c784ad92449743f73af5 Reviewed-on: https://go-review.googlesource.com/30213Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For #16339. Change-Id: Ie2e3338b87e84f45cda0868213bbcd2dae9ab6e3 Reviewed-on: https://go-review.googlesource.com/30212Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For now, we also accept "type p = p.T" (using = instead of =>, for type aliases only), so we can experiment with an approach that only uses type aliases. This concession is implemened in the parser. For #16339 Change-Id: I88b5522a8b6cfc2e97ca146ede8b32af340220f8 Reviewed-on: https://go-review.googlesource.com/30211Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For #16339. Change-Id: I0f83e46f13b5c8801aacf48fc8b690049edbbbff Reviewed-on: https://go-review.googlesource.com/30210Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Carl Mastrangelo authored
Also add a benchmark that shows off the new behavior. The existing benchmarks reuse the same slice, and thus don't ever have to clear memory. Running the Append|Grow benchmarks in runtime: name old time/op new time/op delta AppendSliceLarge/1024Bytes-12 265ns ± 1% 265ns ± 3% ~ (p=0.524 n=17+20) AppendSliceLarge/4096Bytes-12 807ns ± 3% 772ns ± 1% -4.38% (p=0.000 n=20+20) AppendSliceLarge/16384Bytes-12 3.20µs ± 4% 2.82µs ± 4% -11.93% (p=0.000 n=19+20) AppendSliceLarge/65536Bytes-12 13.0µs ± 4% 11.0µs ± 3% -15.22% (p=0.000 n=20+20) AppendSliceLarge/262144Bytes-12 62.7µs ± 1% 51.6µs ± 1% -17.67% (p=0.000 n=19+20) AppendSliceLarge/1048576Bytes-12 337µs ± 3% 289µs ± 3% -14.36% (p=0.000 n=20+20) GrowSliceBytes-12 31.2ns ± 4% 31.4ns ±11% ~ (p=0.308 n=19+18) GrowSliceInts-12 53.4ns ±14% 45.0ns ± 6% -15.74% (p=0.000 n=20+19) GrowSlicePtr-12 87.0ns ± 3% 83.3ns ± 3% -4.26% (p=0.000 n=18+17) GrowSliceStruct24Bytes-12 88.9ns ± 5% 77.8ns ± 2% -12.45% (p=0.000 n=20+19) Append-12 17.2ns ± 1% 17.3ns ± 2% ~ (p=0.464 n=18+17) AppendGrowByte-12 2.28ms ± 1% 1.92ms ± 2% -15.65% (p=0.000 n=20+18) AppendGrowString-12 255ms ± 3% 253ms ± 4% ~ (p=0.065 n=19+19) AppendSlice/1Bytes-12 3.13ns ± 0% 3.11ns ± 1% -0.65% (p=0.000 n=17+18) AppendSlice/4Bytes-12 3.02ns ± 2% 3.11ns ± 1% +3.27% (p=0.000 n=18+17) AppendSlice/7Bytes-12 4.14ns ± 3% 4.13ns ± 2% ~ (p=0.380 n=19+18) AppendSlice/8Bytes-12 3.74ns ± 3% 3.68ns ± 1% -1.76% (p=0.000 n=19+18) AppendSlice/15Bytes-12 4.03ns ± 2% 4.04ns ± 2% ~ (p=0.261 n=19+20) AppendSlice/16Bytes-12 4.03ns ± 2% 4.03ns ± 0% ~ (p=0.062 n=18+17) AppendSlice/32Bytes-12 3.23ns ± 4% 3.43ns ± 1% +6.10% (p=0.000 n=17+18) AppendStr/1Bytes-12 3.51ns ± 1% 3.52ns ± 1% ~ (p=0.321 n=18+19) AppendStr/4Bytes-12 3.46ns ± 1% 3.46ns ± 1% ~ (p=0.977 n=18+20) AppendStr/8Bytes-12 3.18ns ± 1% 3.19ns ± 1% ~ (p=0.650 n=16+17) AppendStr/16Bytes-12 6.08ns ±27% 5.52ns ± 3% -9.16% (p=0.002 n=18+19) AppendStr/32Bytes-12 3.71ns ± 1% 3.53ns ± 1% -4.73% (p=0.000 n=20+19) AppendSpecialCase-12 17.7ns ± 1% 17.8ns ± 3% +0.86% (p=0.045 n=17+18) AppendInPlace/NoGrow/Byte-12 375ns ± 1% 376ns ± 1% +0.35% (p=0.021 n=20+18) AppendInPlace/NoGrow/1Ptr-12 1.01µs ± 1% 1.10µs ± 1% +9.28% (p=0.000 n=18+20) AppendInPlace/NoGrow/2Ptr-12 1.85µs ± 2% 1.71µs ± 1% -7.51% (p=0.000 n=19+18) AppendInPlace/NoGrow/3Ptr-12 2.57µs ± 2% 2.44µs ± 1% -5.08% (p=0.000 n=19+19) AppendInPlace/NoGrow/4Ptr-12 3.52µs ± 2% 3.35µs ± 2% -4.70% (p=0.000 n=20+19) AppendInPlace/Grow/Byte-12 212ns ± 1% 217ns ± 8% +2.57% (p=0.000 n=20+20) AppendInPlace/Grow/1Ptr-12 214ns ± 2% 217ns ± 3% +1.23% (p=0.001 n=18+19) AppendInPlace/Grow/2Ptr-12 298ns ± 2% 300ns ± 2% +0.55% (p=0.038 n=19+20) AppendInPlace/Grow/3Ptr-12 367ns ± 2% 366ns ± 2% ~ (p=0.452 n=20+18) AppendInPlace/Grow/4Ptr-12 416ns ± 2% 411ns ± 2% -1.18% (p=0.000 n=20+19) StackGrowth-12 43.4ns ± 1% 43.4ns ± 0% ~ (p=1.000 n=16+16) StackGrowthDeep-12 11.4µs ± 4% 10.3µs ± 4% -9.65% (p=0.000 n=20+19) Change-Id: I69a8afbd942c787c591d95b9d9439bd6db4d1e49 Reviewed-on: https://go-review.googlesource.com/30192Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
BlockCall was removed in golang.org/cl/28950. Change-Id: Ib8d9f3111bf3dc01956dd776afeb345ede8bc933 Reviewed-on: https://go-review.googlesource.com/30353Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Oleg Vakheta authored
Change-Id: Ie7b869892816a171d8c71612998cc32a190aeff9 Reviewed-on: https://go-review.googlesource.com/17227 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Passes toolstash/buildall. Change-Id: I928a2ef39fb10091957f35bb3f1564498f6f1b83 Reviewed-on: https://go-review.googlesource.com/30312 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Quentin Renard authored
Remove the use of io.ReadAll in http.parsePostForm to avoid converting the whole input from []byte to string and not performing well space-allocated-wise. Instead a new function called parsePostFormURLEncoded is used and is fed directly an io.Reader that is parsed using a bufio.Reader. Benchmark: name old time/op new time/op delta PostQuery-4 2.90µs ± 6% 2.82µs ± 4% ~ (p=0.094 n=9+9) name old alloc/op new alloc/op delta PostQuery-4 1.05kB ± 0% 0.90kB ± 0% -14.49% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PostQuery-4 6.00 ± 0% 7.00 ± 0% +16.67% (p=0.000 n=10+10) Fixes #14655 Change-Id: I112c263d4221d959ed6153cfe88bc57a2aa8ea73 Reviewed-on: https://go-review.googlesource.com/20301Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Todd originally set cmpDepth to 4. Quoting: I picked a depth of 4 by timing tests of `go tool compile arithConst_ssa.go` and `go test -c net/http`. 3.89 / 3.92 CL w/cmpDepth = 1 3.78 / 3.92 CL w/cmpDepth = 2 3.44 / 3.96 CL w/cmpDepth = 3 3.29 / 3.9 CL w/cmpDepth = 4 3.3 / 3.93 CL w/cmpDepth = 5 3.29 / 3.92 CL w/cmpDepth = 10 I don't see the same behavior now, differences in those two benchmarks are in the noise (between 1 and 4). In issue 17127, CSE takes a really long time. Lowering cmpDepth from 4 to 1 lowers compile time from 8 minutes to 1 minute. Fixes #17127 Change-Id: I6dc544bbcf2a9dca73637d0182d3de1a5ae6c944 Reviewed-on: https://go-review.googlesource.com/30257 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Daniel Theophanes authored
Missed one in the prior CL. Change-Id: I6f6d84d52fe4d902a985971a402701fb3b1eed86 Reviewed-on: https://go-review.googlesource.com/30255Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Implementation of spec change https://golang.org/cl/24190/. For #16085. Change-Id: Ib7cb513354269282dfad663c7d2c6e624149f3cd Reviewed-on: https://go-review.googlesource.com/30191Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
Implementation of spec change https://golang.org/cl/24190/. For #16085. Change-Id: I17bbbce38d98a169bc64e84983a7ebfe7142f6e9 Reviewed-on: https://go-review.googlesource.com/30190Reviewed-by: Alan Donovan <adonovan@google.com>
-