- 13 Feb, 2017 2 commits
-
-
Josh Bleecher Snyder authored
Based on sample code from iant. Fixes #18788. Change-Id: I6bb33ed05af2538fbde42ddcac629280ef7c00a6 Reviewed-on: https://go-review.googlesource.com/36892 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Erik Dubbelboer authored
bytes.Equal is written in assembly and is slightly faster than the current Go bytesEqual from the net package. benchcmp: benchmark old ns/op new ns/op delta BenchmarkIPCompare4-8 7.74 7.01 -9.43% BenchmarkIPCompare6-8 8.47 6.86 -19.01% Change-Id: I2a7ad35867489b46f0943aef5776a2fe1b46e2df Reviewed-on: https://go-review.googlesource.com/36850Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 12 Feb, 2017 3 commits
-
-
Alex Brainman authored
For #10424. Change-Id: Ie4e87503b0ed04f65d2444652bd1db647d3529f4 Reviewed-on: https://go-review.googlesource.com/36851Reviewed-by:
-
Russ Cox authored
If there are many goroutines contending for two different locks and both locks hash to the same semaRoot, the scans to find the goroutines for a particular lock can end up being O(n), making n lock acquisitions quadratic. As long as only one actively-used lock hashes to each semaRoot there's no problem, since the list operations in that case are O(1). But when the second actively-used lock hits the same semaRoot, then scans for entries with for a given lock have to scan over the entries for the other lock. Fix this problem by changing the semaRoot to hold only one sudog per unique address. In the running example, this drops the length of that list from O(n) to 2. Then attach other goroutines waiting on the same address to a separate list headed by the sudog in the semaRoot list. Those "same address list" operations are still O(1), so now the example from above works much better. There is still an assumption here that in real programs you don't have many many goroutines queueing up on many many distinct addresses. If we end up with that problem, we can replace the top-level list with a treap. Fixes #17953. Change-Id: I78c5b1a5053845275ab31686038aa4f6db5720b2 Reviewed-on: https://go-review.googlesource.com/36792 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cezar Sa Espinola authored
This change allows greatly reducing memory allocations with a slightly performance improvement as well. Instances of (*png).Encoder can have a optional BufferPool attached to them. This allows reusing temporary buffers used when encoding a new image. This buffers include instances to zlib.Writer and bufio.Writer. Also, buffers for current and previous rows are saved in the encoder instance and reused as long as their cap() is enough to fit the current image row. A new benchmark was added to demonstrate the performance improvement when setting a BufferPool to an Encoder instance: $ go test -bench BenchmarkEncodeGray -benchmem BenchmarkEncodeGray-4 1000 2349584 ns/op 130.75 MB/s 852230 B/op 32 allocs/op BenchmarkEncodeGrayWithBufferPool-4 1000 2241650 ns/op 137.04 MB/s 900 B/op 3 allocs/op Change-Id: I4488201ae53cb2ad010c68c1e0118ee12beae14e Reviewed-on: https://go-review.googlesource.com/34150Reviewed-by:
Nigel Tao <nigeltao@golang.org> Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 11 Feb, 2017 9 commits
-
-
Josh Bleecher Snyder authored
Make the comments a bit clearer and more accurate, in anticipation of updating the code. Change-Id: I1111e6c3405a8688fcd29b809a48a762ff41edaa Reviewed-on: https://go-review.googlesource.com/36833Reviewed-by:
-
Josh Bleecher Snyder authored
When code defines a method on T, the compiler generates a corresponding wrapper method on *T. The first thing the wrapper does is check whether the pointer is nil and if so, call panicwrap. This is done to provide a useful error message. The existing implementation gets its information from arguments set up by the compiler. However, with some trouble, this information can be extracted from the name of the wrapper method itself. Removing the arguments to panicwrap simplifies and shrinks the wrapper method. It also means that the call to panicwrap does not require any stack space. This enables a further optimization on amd64/x86, which is to skip the function prologue if nothing else in the method requires stack space. This is frequently the case in simple, hot methods, such as Less and Swap in sort.Interface implementations. Fixes #19040. Benchmarks for package sort on amd64: name old time/op new time/op delta SearchWrappers-8 104ns ± 1% 104ns ± 1% ~ (p=0.286 n=27+27) SortString1K-8 128µs ± 1% 128µs ± 1% -0.44% (p=0.004 n=30+30) SortString1K_Slice-8 118µs ± 2% 117µs ± 1% ~ (p=0.106 n=30+30) StableString1K-8 18.6µs ± 1% 18.6µs ± 1% ~ (p=0.446 n=28+26) SortInt1K-8 65.9µs ± 1% 60.7µs ± 1% -7.96% (p=0.000 n=28+30) StableInt1K-8 75.3µs ± 2% 72.8µs ± 1% -3.41% (p=0.000 n=30+30) StableInt1K_Slice-8 57.7µs ± 1% 57.7µs ± 1% ~ (p=0.515 n=30+30) SortInt64K-8 6.28ms ± 1% 6.01ms ± 1% -4.19% (p=0.000 n=28+28) SortInt64K_Slice-8 5.04ms ± 1% 5.04ms ± 1% ~ (p=0.927 n=28+27) StableInt64K-8 6.65ms ± 1% 6.38ms ± 1% -3.97% (p=0.000 n=26+30) Sort1e2-8 37.9µs ± 1% 37.2µs ± 1% -1.89% (p=0.000 n=29+27) Stable1e2-8 77.0µs ± 1% 74.7µs ± 1% -3.06% (p=0.000 n=27+30) Sort1e4-8 8.21ms ± 2% 7.98ms ± 1% -2.77% (p=0.000 n=29+30) Stable1e4-8 24.8ms ± 1% 24.3ms ± 1% -2.31% (p=0.000 n=28+30) Sort1e6-8 1.27s ± 4% 1.22s ± 1% -3.42% (p=0.000 n=30+29) Stable1e6-8 5.06s ± 1% 4.92s ± 1% -2.77% (p=0.000 n=25+29) [Geo mean] 731µs 714µs -2.29% Before/after assembly for sort.(*intPairs).Less follows. It can be optimized further, but that's for a follow-up CL. Before: "".(*intPairs).Less t=1 size=214 args=0x20 locals=0x38 0x0000 00000 (<autogenerated>:1) TEXT "".(*intPairs).Less(SB), $56-32 0x0000 00000 (<autogenerated>:1) MOVQ (TLS), CX 0x0009 00009 (<autogenerated>:1) CMPQ SP, 16(CX) 0x000d 00013 (<autogenerated>:1) JLS 204 0x0013 00019 (<autogenerated>:1) SUBQ $56, SP 0x0017 00023 (<autogenerated>:1) MOVQ BP, 48(SP) 0x001c 00028 (<autogenerated>:1) LEAQ 48(SP), BP 0x0021 00033 (<autogenerated>:1) MOVQ 32(CX), BX 0x0025 00037 (<autogenerated>:1) TESTQ BX, BX 0x0028 00040 (<autogenerated>:1) JEQ 55 0x002a 00042 (<autogenerated>:1) LEAQ 64(SP), DI 0x002f 00047 (<autogenerated>:1) CMPQ (BX), DI 0x0032 00050 (<autogenerated>:1) JNE 55 0x0034 00052 (<autogenerated>:1) MOVQ SP, (BX) 0x0037 00055 (<autogenerated>:1) NOP 0x0037 00055 (<autogenerated>:1) FUNCDATA $0, gclocals·4032f753396f2012ad1784f398b170f4(SB) 0x0037 00055 (<autogenerated>:1) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x0037 00055 (<autogenerated>:1) MOVQ ""..this+64(FP), AX 0x003c 00060 (<autogenerated>:1) TESTQ AX, AX 0x003f 00063 (<autogenerated>:1) JEQ $0, 135 0x0041 00065 (<autogenerated>:1) MOVQ (AX), CX 0x0044 00068 (<autogenerated>:1) MOVQ 8(AX), AX 0x0048 00072 (<autogenerated>:1) MOVQ "".i+72(FP), DX 0x004d 00077 (<autogenerated>:1) CMPQ DX, AX 0x0050 00080 (<autogenerated>:1) JCC $0, 128 0x0052 00082 (<autogenerated>:1) SHLQ $4, DX 0x0056 00086 (<autogenerated>:1) MOVQ (CX)(DX*1), DX 0x005a 00090 (<autogenerated>:1) MOVQ "".j+80(FP), BX 0x005f 00095 (<autogenerated>:1) CMPQ BX, AX 0x0062 00098 (<autogenerated>:1) JCC $0, 128 0x0064 00100 (<autogenerated>:1) SHLQ $4, BX 0x0068 00104 (<autogenerated>:1) MOVQ (CX)(BX*1), AX 0x006c 00108 (<autogenerated>:1) CMPQ DX, AX 0x006f 00111 (<autogenerated>:1) SETLT AL 0x0072 00114 (<autogenerated>:1) MOVB AL, "".~r2+88(FP) 0x0076 00118 (<autogenerated>:1) MOVQ 48(SP), BP 0x007b 00123 (<autogenerated>:1) ADDQ $56, SP 0x007f 00127 (<autogenerated>:1) RET 0x0080 00128 (<autogenerated>:1) PCDATA $0, $1 0x0080 00128 (<autogenerated>:1) CALL runtime.panicindex(SB) 0x0085 00133 (<autogenerated>:1) UNDEF 0x0087 00135 (<autogenerated>:1) LEAQ go.string."sort_test"(SB), AX 0x008e 00142 (<autogenerated>:1) MOVQ AX, (SP) 0x0092 00146 (<autogenerated>:1) MOVQ $9, 8(SP) 0x009b 00155 (<autogenerated>:1) LEAQ go.string."intPairs"(SB), AX 0x00a2 00162 (<autogenerated>:1) MOVQ AX, 16(SP) 0x00a7 00167 (<autogenerated>:1) MOVQ $8, 24(SP) 0x00b0 00176 (<autogenerated>:1) LEAQ go.string."Less"(SB), AX 0x00b7 00183 (<autogenerated>:1) MOVQ AX, 32(SP) 0x00bc 00188 (<autogenerated>:1) MOVQ $4, 40(SP) 0x00c5 00197 (<autogenerated>:1) PCDATA $0, $1 0x00c5 00197 (<autogenerated>:1) CALL runtime.panicwrap(SB) 0x00ca 00202 (<autogenerated>:1) UNDEF 0x00cc 00204 (<autogenerated>:1) NOP 0x00cc 00204 (<autogenerated>:1) PCDATA $0, $-1 0x00cc 00204 (<autogenerated>:1) CALL runtime.morestack_noctxt(SB) 0x00d1 00209 (<autogenerated>:1) JMP 0 After: "".(*intPairs).Swap t=1 size=147 args=0x18 locals=0x8 0x0000 00000 (<autogenerated>:1) TEXT "".(*intPairs).Swap(SB), $8-24 0x0000 00000 (<autogenerated>:1) MOVQ (TLS), CX 0x0009 00009 (<autogenerated>:1) SUBQ $8, SP 0x000d 00013 (<autogenerated>:1) MOVQ BP, (SP) 0x0011 00017 (<autogenerated>:1) LEAQ (SP), BP 0x0015 00021 (<autogenerated>:1) MOVQ 32(CX), BX 0x0019 00025 (<autogenerated>:1) TESTQ BX, BX 0x001c 00028 (<autogenerated>:1) JEQ 43 0x001e 00030 (<autogenerated>:1) LEAQ 16(SP), DI 0x0023 00035 (<autogenerated>:1) CMPQ (BX), DI 0x0026 00038 (<autogenerated>:1) JNE 43 0x0028 00040 (<autogenerated>:1) MOVQ SP, (BX) 0x002b 00043 (<autogenerated>:1) NOP 0x002b 00043 (<autogenerated>:1) FUNCDATA $0, gclocals·e6397a44f8e1b6e77d0f200b4fba5269(SB) 0x002b 00043 (<autogenerated>:1) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x002b 00043 (<autogenerated>:1) MOVQ ""..this+16(FP), AX 0x0030 00048 (<autogenerated>:1) TESTQ AX, AX 0x0033 00051 (<autogenerated>:1) JEQ $0, 140 0x0035 00053 (<autogenerated>:1) MOVQ (AX), CX 0x0038 00056 (<autogenerated>:1) MOVQ 8(AX), AX 0x003c 00060 (<autogenerated>:1) MOVQ "".i+24(FP), DX 0x0041 00065 (<autogenerated>:1) CMPQ DX, AX 0x0044 00068 (<autogenerated>:1) JCC $0, 133 0x0046 00070 (<autogenerated>:1) SHLQ $4, DX 0x004a 00074 (<autogenerated>:1) MOVQ 8(CX)(DX*1), BX 0x004f 00079 (<autogenerated>:1) MOVQ (CX)(DX*1), SI 0x0053 00083 (<autogenerated>:1) MOVQ "".j+32(FP), DI 0x0058 00088 (<autogenerated>:1) CMPQ DI, AX 0x005b 00091 (<autogenerated>:1) JCC $0, 133 0x005d 00093 (<autogenerated>:1) SHLQ $4, DI 0x0061 00097 (<autogenerated>:1) MOVQ 8(CX)(DI*1), AX 0x0066 00102 (<autogenerated>:1) MOVQ (CX)(DI*1), R8 0x006a 00106 (<autogenerated>:1) MOVQ R8, (CX)(DX*1) 0x006e 00110 (<autogenerated>:1) MOVQ AX, 8(CX)(DX*1) 0x0073 00115 (<autogenerated>:1) MOVQ SI, (CX)(DI*1) 0x0077 00119 (<autogenerated>:1) MOVQ BX, 8(CX)(DI*1) 0x007c 00124 (<autogenerated>:1) MOVQ (SP), BP 0x0080 00128 (<autogenerated>:1) ADDQ $8, SP 0x0084 00132 (<autogenerated>:1) RET 0x0085 00133 (<autogenerated>:1) PCDATA $0, $1 0x0085 00133 (<autogenerated>:1) CALL runtime.panicindex(SB) 0x008a 00138 (<autogenerated>:1) UNDEF 0x008c 00140 (<autogenerated>:1) PCDATA $0, $1 0x008c 00140 (<autogenerated>:1) CALL runtime.panicwrap(SB) 0x0091 00145 (<autogenerated>:1) UNDEF Change-Id: I15bb8435f0690badb868799f313ed8817335efd3 Reviewed-on: https://go-review.googlesource.com/36809 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Follow-up to CL 36791. Change-Id: I1c4831e5dfe90c205782e970ada7faff8a009daa Reviewed-on: https://go-review.googlesource.com/36890Reviewed-by:
-
Dhananjay Nakrani authored
Add temporaries to reorder the assignment for OAS2XXX nodes. This makes orderstmt(), rewrite a, b, c = ... as tmp1, tmp2, tmp3 = ... a, b, c = tmp1, tmp2, tmp3 and a, ok = ... as t1, t2 = ... a = t1 ok = t2 Fixes #13433. Change-Id: Id0f5956e3a254d0a6f4b89b5f7b0e055b1f0e21f Reviewed-on: https://go-review.googlesource.com/34713 Run-TryBot: Dhananjay Nakrani <dhananjayn@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Paul Jolly authored
Encourage people towards the various help forums as a first port of call. Better sign-posting will reduce the incidence or questions being asked in the issue tracker that should otherwise be handled elsewhere, thereby keeping the issue tracker email traffic more focussed. Change-Id: I13b2e498d88be010fca421067ae6fb579a46d6b7 Reviewed-on: https://go-review.googlesource.com/34250Reviewed-by:
-
Alberto Donizetti authored
Using 'sep' as parameter name for strings functions that take a separator argument is fine, but for functions like Index or Count that look for a substring it's better to use 'substr' (like Contains already does). Fixes #19039 Change-Id: Idd557409c8fea64ce830ab0e3fec37d3d56a79f0 Reviewed-on: https://go-review.googlesource.com/36874 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Remi Gillig authored
The environment variables used in those tests override the default OS ones. However, one of them (SystemRoot) seems to be required on some Windows systems for invoking cmd.exe properly. This fixes #4930 and #6568. Change-Id: I23dfb67c1de86020711a3b59513f6adcbba12561 Reviewed-on: https://go-review.googlesource.com/36873Reviewed-by:
-
Jaana Burcu Dogan authored
Change-Id: Ia2852666ef44e7ef0bba2360e92caccc83fd0e5c Reviewed-on: https://go-review.googlesource.com/36796Reviewed-by:
-
Josh Bleecher Snyder authored
When running benchmarks with -cpuprofile, the entire process gets profiled, and ReadMemStats is surprisingly expensive. Running the sort benchmarks right now with -cpuprofile shows almost half of all execution time in ReadMemStats. Since ReadMemStats is not required if the benchmark does not need allocation stats, simply skip it. This will make cpu profiles nicer to read and significantly speed up the process of running benchmarks. It might also make sense to toggle cpu profiling on/off as we begin/end individual benchmarks, but that wouldn't get us the time savings of skipping ReadMemStats, so this CL is useful in itself. Change-Id: I425197b1ee11be4bc91d22b929e2caf648ebd7c5 Reviewed-on: https://go-review.googlesource.com/36791 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 10 Feb, 2017 26 commits
-
-
Nigel Tao authored
The 0x10101 magic constant is a little more principled than 0x10100, as the rounding adjustment now spans the complete range [0, 0xffff] instead of [0, 0xff00]. Consider this round-tripping code: y, cb, cr := color.RGBToYCbCr(r0, g0, b0) r1, g1, b1 := color.YCbCrToRGB(y, cb, cr) Due to rounding errors both ways, we often but not always get a perfect round trip (where r0 == r1 && g0 == g1 && b0 == b1). This is true both before and after this commit. In some cases we got luckier, in others we got unluckier. For example, before this commit, (180, 135, 164) doesn't round trip perfectly (it's off by 1) but (180, 135, 165) does. After this commit, both cases are reversed: the former does and the latter doesn't (again off by 1). Over all possible (r, g, b) triples, there doesn't seem to be a big change for better or worse. There is some history in these CLs: image/color: tweak the YCbCr to RGBA conversion formula. https://go-review.googlesource.com/#/c/12220/2/src/image/color/ycbcr.go image/color: have YCbCr.RGBA work in 16-bit color, per the Color interface. https://go-review.googlesource.com/#/c/8073/2/src/image/color/ycbcr.go Change-Id: Ib25ba7039f49feab2a9d1a4141b86db17db7b3e1 Reviewed-on: https://go-review.googlesource.com/36732 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Instead we can just call needwritebarrier when constructing the SSA representation. Change-Id: I6fefaad49daada9cdb3050f112889e49dca0047b Reviewed-on: https://go-review.googlesource.com/34566Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ian Lance Taylor authored
Fixes #18975. Change-Id: I60dfb299233ecfed4b2da93750ea84e7921f1fbb Reviewed-on: https://go-review.googlesource.com/36482 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
bradfitz noted in change 36717 that the new behavior was no longer comparable with the old. This change restores comparable behavior for -cpu=1. BenchmarkMapAddSame 909 909 +0.00% BenchmarkMapAddSame-6 1309 262 -79.98% BenchmarkMapAddDifferent 2856 3030 +6.09% BenchmarkMapAddDifferent-6 3803 581 -84.72% updates #18177 Change-Id: Ifaff5a1f48be92002d86c296220313b7efdc81d6 Reviewed-on: https://go-review.googlesource.com/36723Reviewed-by:
-
Mark Adams authored
The existing implementation uses v1.0 of Bitbucket's REST API. The newer version 2.0 of Bitbucket's REST API provides the same information but with support for partial responses allowing the client to request only the response fields that are relevant to their usage of the API resulting in a much smaller payload size. The partial response functionality in the Bitbucket API is documented here: https://developer.atlassian.com/bitbucket/api/2/reference/meta/partial-response The v2.0 of the Bitbucket repositories API is documented here: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D#get Fixes #18919 Change-Id: I319947d5c51adc241cfe3a2228a667cc43fb1f56 Reviewed-on: https://go-review.googlesource.com/36219 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alan Donovan authored
Change-Id: Ieb0808caa24c9a5e599084183ba5ee8a6536f7d8 Reviewed-on: https://go-review.googlesource.com/36622Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Sokolov Yura authored
So it could be inlined. Using bit-tricks it could be implemented without condition (improved trick version by Minux Ma). Simple benchmark shows it is faster on i386 and x86_64, though I don't know will it be faster on other architectures? benchmark old ns/op new ns/op delta BenchmarkFastrand-3 2.79 1.48 -46.95% BenchmarkFastrandHashiter-3 25.9 24.9 -3.86% Change-Id: Ie2eb6d0f598c0bb5fac7f6ad0f8b5e3eddaa361b Reviewed-on: https://go-review.googlesource.com/34782Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
If the user is calling SetGCPercent(-1), they intend to disable GC. They probably don't intend to run one. If they do, they can call runtime.GC themselves. Change-Id: I40ef40dfc7e15193df9ff26159cd30e56b666f73 Reviewed-on: https://go-review.googlesource.com/34013 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Heschi Kreinick authored
During the mark phase of garbage collection, goroutines that allocate may be recruited to assist. This change creates trace events for mark assists and displays them similarly to sweep assists in the trace viewer. Mark assists are different than sweeps in that they can be preempted, so displaying them in the trace viewer is a little tricky -- we may need to synthesize multiple slices for one mark assist. This could have been done in the parser instead, but I thought it might be preferable to keep the parser as true to the event stream as possible. Change-Id: I381dcb1027a187a354b1858537851fa68a620ea7 Reviewed-on: https://go-review.googlesource.com/36015 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Hajime Hoshi authored
Change-Id: Ib2109ab773fbf2a35188300cf91a54735f75fc7c Reviewed-on: https://go-review.googlesource.com/36736Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Bryan C. Mills authored
The other expvar tests are already parallelized, and this will help to measure the impact of potential implementations for #18177. updates #18177 Change-Id: I0f4f1a16a0285556cbcc8339855b6459af412675 Reviewed-on: https://go-review.googlesource.com/36717Reviewed-by:
-
Michael Hudson-Doyle authored
Otherwise, calling PtrTo on the result will fail. Fixes #19003 Change-Id: I8d7d1981a5d0417d5aee52740469d71e90734963 Reviewed-on: https://go-review.googlesource.com/36731 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David R. Jenni authored
Change code of the form `i + (j-i)/2` to `int(uint(i+j) >> 1)`. The optimized average calculation uses fewer instructions to calculate the average without overflowing at the addition. Analogous to https://golang.org/cl/36332. name old time/op new time/op delta StableString1K-4 49.6µs ± 3% 49.1µs ± 8% ~ (p=0.659 n=16+19) StableInt1K-4 160µs ±10% 148µs ± 5% -7.29% (p=0.000 n=20+16) StableInt1K_Slice-4 139µs ± 4% 136µs ± 3% -2.52% (p=0.000 n=20+16) StableInt64K-4 8.84ms ± 6% 8.57ms ± 5% -3.07% (p=0.001 n=20+19) Stable1e2-4 162µs ±19% 147µs ±16% -8.79% (p=0.002 n=20+20) Stable1e4-4 31.0ms ± 5% 30.6ms ± 5% ~ (p=0.221 n=20+20) Stable1e6-4 6.37s ± 3% 6.27s ± 2% -1.67% (p=0.000 n=19+20) Change-Id: I1cea0bcb9ace8ef7e48b8fab772e41b4b2170da9 Reviewed-on: https://go-review.googlesource.com/36570 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
name old time/op new time/op delta Hash8Bytes-6 913ns ± 0% 667ns ± 0% -26.91% (p=0.000 n=10+10) Hash1K-6 6.58µs ± 0% 4.23µs ± 0% -35.69% (p=0.000 n=10+9) Hash8K-6 45.9µs ± 0% 28.1µs ± 0% -38.93% (p=0.000 n=10+10) name old speed new speed delta Hash8Bytes-6 8.76MB/s ± 0% 11.99MB/s ± 0% +36.87% (p=0.000 n=10+8) Hash1K-6 156MB/s ± 0% 242MB/s ± 0% +55.49% (p=0.000 n=10+9) Hash8K-6 178MB/s ± 0% 292MB/s ± 0% +63.74% (p=0.000 n=10+10) Change-Id: Ic9211d68b02935b2195995f264ec57d6bc36f713 Reviewed-on: https://go-review.googlesource.com/36630 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
The code previously tested only whether DNS-name SANs were present in a certificate which is only approximately correct. In fact, /any/ SAN extension, including one with no DNS names, should cause the CN to be ignored. Change-Id: I3d9824918975be6d4817e7cbb48ed1b0c5a2fc8b Reviewed-on: https://go-review.googlesource.com/36696 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
The s390x port was based on the ppc64 port and, because of the way the port was done, inherited some instructions from it. ppc64 supports 3-operand (4-operand for FMADD etc.) floating point instructions but s390x doesn't (the destination register is always an input) and so these were emulated. There is a bug in the emulation of FMADD whereby if the destination register is also a source for the multiplication it will be clobbered. This doesn't break any assembly code in the std lib but could affect future work. To fix this I have gone through the floating point instructions and removed all unnecessary 3-/4-operand emulation. The compiler doesn't need it and assembly writers don't need it, it's just a source of bugs. I've also deleted the FNMADD family of emulated instructions. They aren't used anywhere. Change-Id: Ic07cedcf141a6a3b43a0c84895460f6cfbf56c04 Reviewed-on: https://go-review.googlesource.com/33350 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
Unlike the pure go implementation used by every other architecture, the amd64 asm implementation of Exp does not fail early if the argument is known to overflow. Make it fail early. Cost of the check is < 1ns (on an old Sandy Bridge machine): name old time/op new time/op delta Exp-4 18.3ns ± 1% 18.7ns ± 1% +2.08% (p=0.000 n=18+20) Fixes #14932 Fixes #18912 Change-Id: I04b3f9b4ee853822cbdc97feade726fbe2907289 Reviewed-on: https://go-review.googlesource.com/36271 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by:
-
Tuo Shan authored
Fixes #18730. Change-Id: If3ef28e62f7e449d4c8dc1dfd78f7d6f5a87ed26 Reviewed-on: https://go-review.googlesource.com/36478Reviewed-by:
-
Daniel Theophanes authored
Previously if a connection was requested but timed out during the request and when acquiring the db.Lock the connection request is fulfilled and the request is unable to be returned to the connection pool, then then driver connection would not be closed. No tests were added or modified because I was unable to determine how to trigger this situation without something invasive. Change-Id: I9d4dc680e3fdcf63d79d212174a5b8b313f363f1 Reviewed-on: https://go-review.googlesource.com/36641Reviewed-by:
-
Russ Cox authored
These are very tightly coupled, and internal/protopprof is small. There's no point to having a separate package. Change-Id: I2c8aa49c9e18a7128657bf2b05323860151b5606 Reviewed-on: https://go-review.googlesource.com/36711 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nigel Tao authored
This is a re-roll of a previous commit, a855da29, which was rolled back in 14347ee4. It was rolled back because it broke a unit test in image/gif. The image/gif code was fixed by 9ef65dbe "image/gif: fix frame-inside-image bounds checking". The original commit message: image: fix the overlap check in Rectangle.Intersect. The doc comment for Rectangle.Intersect clearly states, "If the two rectangles do not overlap then the zero rectangle will be returned." Prior to this fix, calling Intersect on adjacent but non-overlapping rectangles would return an empty but non-zero rectangle. The fix essentially changes if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc } to if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc } (note that the > signs have become >= signs), but changing that line to: if r.Empty() { etc } seems clearer (and equivalent). Change-Id: I2e3af1f1686064a573b2e513b39246fe60c03631 Reviewed-on: https://go-review.googlesource.com/36734Reviewed-by:
-
Josh Bleecher Snyder authored
CL 35554 taught order.go to use static variables for constants that needed to be addressable for runtime routines. However, there is one class of runtime routines that do not actually need an addressable value: fast map access routines. This CL teaches order.go to avoid using static variables for addressability in those cases. Instead, it avoids introducing a temp at all, which the backend would just have to optimize away. Fixes #19015. Change-Id: I5ef780c604fac3fb48dabb23a344435e283cb832 Reviewed-on: https://go-review.googlesource.com/36693Reviewed-by:
-
Nigel Tao authored
The semantics of the Go image.Rectangle type is that the In and Intersects methods treat empty rectangles specially. There are multiple valid representations of an empty image.Rectangle. One of them is the zero image.Rectangle but there are others. They're obviously not all equal in the == sense, so we shouldn't use != to check GIF's semantics. This change will allow us to re-roll a855da29 "image: fix the overlap check in Rectangle.Intersect" which was rolled back in 14347ee4. Change-Id: Ie1a0d092510a7bb6170e61adbf334b21361ff9e6 Reviewed-on: https://go-review.googlesource.com/36639 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nathan Caza authored
The current implementation fails to produce an "IsNotExist" error on some platforms (unix) for certain situations where it would be expected. This causes downstream consumers, like FileServer, to emit 500 errors instead of a 404 for some non-existant paths on certain platforms but not others. As an example, os.Open("/index.html/foo") on a unix-type system will return syscall.ENOTDIR, which os.IsNotExist cannot return true for (because the error code is ambiguous without context). On windows, this same example would result in os.IsNotExist returning true -- since the returned error is specific. This change alters Dir.Open to look up the tree for an "IsPermission" or "IsNotExist" error to return, or a non-directory, returning os.ErrNotExist in the last case. For all other error scenarios, the original error is returned. This ensures that downstream code, like FileServer, receive errors that behave the same across all platforms. Fixes #18984 Change-Id: Id7d16591c24cd96afddb6d8ae135ac78da42ed37 Reviewed-on: https://go-review.googlesource.com/36635Reviewed-by:Yasuhiro MATSUMOTO <mattn.jp@gmail.com> Reviewed-by:
-
Robert Griesemer authored
We missed this in https://golang.org/cl/36213. Thanks to Chris Hines for pointing it out. For #18130. Change-Id: I6279ab19966c4391c4b4458b21fd2527d3f949dd Reviewed-on: https://go-review.googlesource.com/36691Reviewed-by:
-
Robert Griesemer authored
The gcCompat mode was introduced to match the new parser's node position setup exactly with the positions used by the original parser. Some of the gcCompat adjustments were required to satisfy syntax error test cases, and the rest were required to make toolstash cmp pass. This change removes the former gcCompat adjustments and instead adjusts the respective test cases as necessary. In some cases this makes the error lines consistent with the ones reported by gccgo. Where it has changed, the position associated with a given syntactic construct is the position (line/col number) of the left-most token belonging to the construct. Change-Id: I5b60c00c5999a895c4d6d6e9b383c6405ccf725c Reviewed-on: https://go-review.googlesource.com/36695 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
