- 28 Aug, 2019 20 commits
-
-
Daniel Martí authored
The net/url error in question now quotes the URL, so update the expected output string. While at it, also update a comment in httputil, though that doesn't affect any test. Fixes #33910. Change-Id: I0981f528b24337c2952ef60c0db3b7ff72d72110 Reviewed-on: https://go-review.googlesource.com/c/go/+/192078 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
This reverts CL 189277. Reason for revert: broke 32-bit builders. Updates #33902 Change-Id: Ie5f180d0371a90e5057ed578c334372e5fc3a286 Reviewed-on: https://go-review.googlesource.com/c/go/+/192097 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
Nao YONASHIRO authored
Use local index variable to help the go compiler use a register to for the hash index instead of continuous memory read and write operations. compress/flate: Encode/Digits/Huffman/1e4-4 35.3µs ± 1% 32.7µs ± 0% -7.48% (p=0.000 n=17+19) Encode/Digits/Huffman/1e5-4 330µs ± 0% 312µs ± 0% -5.55% (p=0.000 n=17+18) Encode/Digits/Huffman/1e6-4 3.30ms ± 0% 3.12ms ± 0% -5.64% (p=0.000 n=18+19) Encode/Digits/Speed/1e4-4 157µs ± 0% 156µs ± 0% -0.41% (p=0.000 n=17+19) Encode/Digits/Speed/1e5-4 1.46ms ± 0% 1.46ms ± 1% ~ (p=0.478 n=20+19) Encode/Digits/Speed/1e6-4 14.4ms ± 0% 14.4ms ± 0% ~ (p=0.835 n=19+20) Encode/Digits/Default/1e4-4 309µs ± 0% 310µs ± 0% +0.23% (p=0.000 n=19+17) Encode/Digits/Default/1e5-4 4.76ms ± 0% 4.76ms ± 0% ~ (p=0.297 n=19+19) Encode/Digits/Default/1e6-4 51.0ms ± 0% 51.0ms ± 1% ~ (p=0.233 n=18+19) Encode/Digits/Compression/1e4-4 309µs ± 0% 310µs ± 0% +0.21% (p=0.000 n=17+20) Encode/Digits/Compression/1e5-4 4.76ms ± 0% 4.76ms ± 0% ~ (p=0.749 n=20+19) Encode/Digits/Compression/1e6-4 50.9ms ± 0% 50.9ms ± 0% ~ (p=0.499 n=18+19) Encode/Newton/Huffman/1e4-4 51.9µs ± 0% 48.0µs ± 0% -7.61% (p=0.000 n=19+19) Encode/Newton/Huffman/1e5-4 396µs ± 0% 377µs ± 0% -4.79% (p=0.000 n=18+19) Encode/Newton/Huffman/1e6-4 3.95ms ± 0% 3.74ms ± 0% -5.21% (p=0.000 n=20+17) Encode/Newton/Speed/1e4-4 155µs ± 0% 154µs ± 0% -0.67% (p=0.000 n=17+18) Encode/Newton/Speed/1e5-4 1.17ms ± 0% 1.16ms ± 0% -0.64% (p=0.000 n=20+16) Encode/Newton/Speed/1e6-4 11.6ms ± 0% 11.5ms ± 0% -0.63% (p=0.000 n=19+20) Encode/Newton/Default/1e4-4 347µs ± 0% 347µs ± 0% ~ (p=0.744 n=20+19) Encode/Newton/Default/1e5-4 5.06ms ± 0% 5.02ms ± 0% -0.77% (p=0.000 n=20+19) Encode/Newton/Default/1e6-4 53.3ms ± 1% 52.8ms ± 0% -0.91% (p=0.000 n=18+16) Encode/Newton/Compression/1e4-4 351µs ± 0% 351µs ± 0% ~ (p=0.277 n=20+20) Encode/Newton/Compression/1e5-4 6.90ms ± 0% 6.85ms ± 0% -0.61% (p=0.000 n=19+18) Encode/Newton/Compression/1e6-4 73.2ms ± 0% 72.8ms ± 0% -0.52% (p=0.000 n=18+18) name old speed new speed delta Encode/Digits/Huffman/1e4-4 283MB/s ± 1% 306MB/s ± 0% +8.09% (p=0.000 n=17+19) Encode/Digits/Huffman/1e5-4 303MB/s ± 0% 321MB/s ± 0% +5.87% (p=0.000 n=18+18) Encode/Digits/Huffman/1e6-4 303MB/s ± 0% 321MB/s ± 0% +5.98% (p=0.000 n=18+19) Encode/Digits/Speed/1e4-4 63.9MB/s ± 0% 64.2MB/s ± 0% +0.41% (p=0.000 n=17+19) Encode/Digits/Speed/1e5-4 68.5MB/s ± 0% 68.4MB/s ± 1% ~ (p=0.481 n=20+19) Encode/Digits/Speed/1e6-4 69.4MB/s ± 0% 69.3MB/s ± 0% ~ (p=0.712 n=19+20) Encode/Digits/Default/1e4-4 32.3MB/s ± 0% 32.3MB/s ± 0% -0.23% (p=0.000 n=19+17) Encode/Digits/Default/1e5-4 21.0MB/s ± 0% 21.0MB/s ± 0% ~ (p=0.460 n=19+19) Encode/Digits/Default/1e6-4 19.6MB/s ± 0% 19.6MB/s ± 1% ~ (p=0.180 n=18+19) Encode/Digits/Compression/1e4-4 32.3MB/s ± 0% 32.3MB/s ± 0% -0.21% (p=0.000 n=17+20) Encode/Digits/Compression/1e5-4 21.0MB/s ± 0% 21.0MB/s ± 0% ~ (p=0.700 n=20+19) Encode/Digits/Compression/1e6-4 19.6MB/s ± 0% 19.6MB/s ± 0% ~ (p=0.486 n=18+19) Encode/Newton/Huffman/1e4-4 193MB/s ± 0% 208MB/s ± 0% +8.23% (p=0.000 n=19+19) Encode/Newton/Huffman/1e5-4 252MB/s ± 0% 265MB/s ± 0% +5.04% (p=0.000 n=18+19) Encode/Newton/Huffman/1e6-4 253MB/s ± 0% 267MB/s ± 0% +5.49% (p=0.000 n=20+17) Encode/Newton/Speed/1e4-4 64.5MB/s ± 0% 65.0MB/s ± 0% +0.67% (p=0.000 n=17+18) Encode/Newton/Speed/1e5-4 85.7MB/s ± 0% 86.3MB/s ± 0% +0.65% (p=0.000 n=20+16) Encode/Newton/Speed/1e6-4 86.2MB/s ± 0% 86.7MB/s ± 0% +0.63% (p=0.000 n=19+20) Encode/Newton/Default/1e4-4 28.9MB/s ± 0% 28.9MB/s ± 0% ~ (p=0.840 n=20+19) Encode/Newton/Default/1e5-4 19.8MB/s ± 0% 19.9MB/s ± 0% +0.78% (p=0.000 n=20+19) Encode/Newton/Default/1e6-4 18.8MB/s ± 1% 18.9MB/s ± 0% +0.93% (p=0.000 n=18+16) Encode/Newton/Compression/1e4-4 28.5MB/s ± 0% 28.5MB/s ± 0% ~ (p=0.244 n=20+20) Encode/Newton/Compression/1e5-4 14.5MB/s ± 0% 14.6MB/s ± 0% +0.61% (p=0.000 n=19+18) Encode/Newton/Compression/1e6-4 13.7MB/s ± 0% 13.7MB/s ± 0% +0.53% (p=0.000 n=18+18) image/png: name old time/op new time/op delta EncodeGray-4 2.16ms ± 1% 1.85ms ± 1% -14.17% (p=0.000 n=86+91) EncodeGrayWithBufferPool-4 1.99ms ± 0% 1.69ms ± 0% -15.09% (p=0.000 n=97+94) EncodeNRGBOpaque-4 6.51ms ± 1% 5.62ms ± 1% -13.66% (p=0.000 n=90+92) EncodeNRGBA-4 7.33ms ± 1% 6.12ms ± 1% -16.49% (p=0.000 n=89+90) EncodePaletted-4 5.10ms ± 1% 4.96ms ± 1% -2.76% (p=0.000 n=90+87) EncodeRGBOpaque-4 6.51ms ± 1% 5.63ms ± 1% -13.49% (p=0.000 n=94+87) EncodeRGBA-4 24.3ms ± 2% 23.0ms ± 0% -5.23% (p=0.000 n=91+89) name old speed new speed delta EncodeGray-4 142MB/s ± 1% 166MB/s ± 1% +16.50% (p=0.000 n=86+91) EncodeGrayWithBufferPool-4 154MB/s ± 0% 182MB/s ± 0% +17.78% (p=0.000 n=97+94) EncodeNRGBOpaque-4 189MB/s ± 1% 219MB/s ± 1% +15.82% (p=0.000 n=90+93) EncodeNRGBA-4 168MB/s ± 1% 201MB/s ± 1% +19.75% (p=0.000 n=89+90) EncodePaletted-4 60.3MB/s ± 1% 62.0MB/s ± 1% +2.84% (p=0.000 n=90+87) EncodeRGBOpaque-4 189MB/s ± 1% 218MB/s ± 1% +15.60% (p=0.000 n=94+87) EncodeRGBA-4 50.6MB/s ± 2% 53.4MB/s ± 0% +5.51% (p=0.000 n=91+89) Change-Id: Ifed4486a7ba19a26abe5cbf2142f15cc7464e84f Reviewed-on: https://go-review.googlesource.com/c/go/+/187837 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Stefan Baebler authored
Current implementation doesn't always make it obvious what the exact problem with the URL is, so this makes it clearer by consistently quoting the invalid URL, as is the norm in other parsing implementations, eg.: strconv.Atoi(" 123") returns an error: parsing " 123": invalid syntax Updates #29261 Change-Id: Icc6bff8b4a4584677c0f769992823e6e1e0d397d GitHub-Last-Rev: 648b9d93fe149ec90f3aeca73019158a344de03e GitHub-Pull-Request: golang/go#29384 Reviewed-on: https://go-review.googlesource.com/c/go/+/185117Reviewed-by: -
Martin Möhrmann authored
Pre-allocate the slice of labels with enough capacity to avoid growslice calls. Change-Id: I89db59ac722c03b0202e042d1f707bb041e0999f Reviewed-on: https://go-review.googlesource.com/c/go/+/181517 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Eddie Scholtz authored
Per the code review guidelines: "Words in names that are initialisms or acronyms have a consistent case." Change-Id: I347b02d2f48455f2cbbc040191ba197e3e8f23fc Reviewed-on: https://go-review.googlesource.com/c/go/+/191970Reviewed-by:
-
Martin Möhrmann authored
Production profiling shows ~15% of url.Parse time being spend in the overhead of calling strings.IndexByte through strings.Index instead of calling strings.IndexByte directly. name old time/op new time/op delta Split 15.5ns ± 2% 10.7ns ± 3% -30.98% (p=0.000 n=20+19) Change-Id: Ie25dd4afa93539a1335a91ab2a4a367f97bd3df0 Reviewed-on: https://go-review.googlesource.com/c/go/+/178877 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Cuong Manh Le authored
golang.org/cl/143180 changed gc.eqtype to types.Identical, but gc.eqtype is still mentioned in some comments. Remove them and update comments to mention new functions instead. Change-Id: I6c5eece5221f524556ee55db80de0e4bdfaf166e Reviewed-on: https://go-review.googlesource.com/c/go/+/191357Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Nao YONASHIRO authored
The existing implementation has calculated pixels per byte for each pixel. reduce the calculation of pixels per byte. name old time/op new time/op delta EncodeGray-4 2.16ms ± 1% 2.16ms ± 1% -0.28% (p=0.000 n=86+84) EncodeGrayWithBufferPool-4 1.99ms ± 0% 1.97ms ± 0% -0.72% (p=0.000 n=97+92) EncodeNRGBOpaque-4 6.51ms ± 1% 6.48ms ± 1% -0.45% (p=0.000 n=90+85) EncodeNRGBA-4 7.33ms ± 1% 7.28ms ± 0% -0.69% (p=0.000 n=89+87) EncodePaletted-4 5.10ms ± 1% 2.29ms ± 0% -55.11% (p=0.000 n=90+85) EncodeRGBOpaque-4 6.51ms ± 1% 6.51ms ± 0% ~ (p=0.311 n=94+88) EncodeRGBA-4 24.3ms ± 2% 24.1ms ± 1% -0.87% (p=0.000 n=91+91) name old speed new speed delta EncodeGray-4 142MB/s ± 1% 143MB/s ± 1% +0.26% (p=0.000 n=86+85) EncodeGrayWithBufferPool-4 154MB/s ± 0% 156MB/s ± 0% +0.73% (p=0.000 n=97+92) EncodeNRGBOpaque-4 189MB/s ± 1% 190MB/s ± 1% +0.44% (p=0.000 n=90+86) EncodeNRGBA-4 168MB/s ± 1% 169MB/s ± 0% +0.69% (p=0.000 n=89+87) EncodePaletted-4 60.3MB/s ± 1% 134.2MB/s ± 0% +122.74% (p=0.000 n=90+85) EncodeRGBOpaque-4 189MB/s ± 1% 189MB/s ± 0% ~ (p=0.326 n=94+88) EncodeRGBA-4 50.6MB/s ± 2% 51.1MB/s ± 1% +0.87% (p=0.000 n=91+91) name old alloc/op new alloc/op delta EncodeGray-4 852kB ± 0% 852kB ± 0% +0.00% (p=0.000 n=100+100) EncodeGrayWithBufferPool-4 1.49kB ± 2% 1.47kB ± 1% -0.88% (p=0.000 n=95+90) EncodeNRGBOpaque-4 860kB ± 0% 860kB ± 0% +0.00% (p=0.003 n=98+58) EncodeNRGBA-4 864kB ± 0% 864kB ± 0% +0.00% (p=0.021 n=100+99) EncodePaletted-4 849kB ± 0% 849kB ± 0% +0.00% (p=0.040 n=100+100) EncodeRGBOpaque-4 860kB ± 0% 860kB ± 0% ~ (p=0.062 n=66+98) EncodeRGBA-4 3.32MB ± 0% 3.32MB ± 0% -0.00% (p=0.044 n=99+99) name old allocs/op new allocs/op delta EncodeGray-4 32.0 ± 0% 32.0 ± 0% ~ (all equal) EncodeGrayWithBufferPool-4 3.00 ± 0% 3.00 ± 0% ~ (all equal) EncodeNRGBOpaque-4 32.0 ± 0% 32.0 ± 0% ~ (all equal) EncodeNRGBA-4 32.0 ± 0% 32.0 ± 0% ~ (all equal) EncodePaletted-4 36.0 ± 0% 36.0 ± 0% ~ (all equal) EncodeRGBOpaque-4 32.0 ± 0% 32.0 ± 0% ~ (all equal) EncodeRGBA-4 614k ± 0% 614k ± 0% ~ (all equal) Change-Id: I716bde2dc80d8111d75d3d765fc09223f770d5a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/187417Reviewed-by:
Nigel Tao <nigeltao@golang.org> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Agniva De Sarker authored
Extend the optimization introduced in CL 141118 to the wasm architecture. And for reference, the rules trigger 212 times while building std and cmd $GOOS=js GOARCH=wasm gotip build std cmd $grep -E "Wasm.rules:44(1|2|3|4)" rulelog | wc -l 212 Updates #26498 Change-Id: I153684a2b98589ae812b42268da08b65679e09d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/185477 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com> Reviewed-by:
Richard Musiol <neelance@gmail.com>
-
Agniva De Sarker authored
Currently, every call to mem() incurs a new DataView object. This was necessary because the wasm linear memory could grow at any time. Now, whenever the memory grows, we make a call to the front-end. This allows us to reuse the existing DataView object and create a new one only when the memory actually grows. This gives us a boost in performance during DOM operations, while incurring an extra trip to front-end when memory grows. However, since the GrowMemory calls are meant to decrease over the runtime of an application, this is a good tradeoff in the long run. The benchmarks have been tested inside a browser (Google Chrome 75.0.3770.90 (Official Build) (64-bit)). It is hard to get stable nos. for DOM operations since the jumps make the timing very unreliable. But overall, it shows a clear gain. name old time/op new time/op delta DOM 135µs ±26% 84µs ±10% -37.22% (p=0.000 n=10+9) Go1 benchmarks do not show any noticeable degradation: name old time/op new time/op delta BinaryTree17 22.5s ± 0% 22.5s ± 0% ~ (p=0.743 n=8+9) Fannkuch11 15.1s ± 0% 15.1s ± 0% +0.17% (p=0.000 n=9+9) FmtFprintfEmpty 324ns ± 1% 303ns ± 0% -6.64% (p=0.000 n=9+10) FmtFprintfString 535ns ± 1% 515ns ± 0% -3.85% (p=0.000 n=10+10) FmtFprintfInt 609ns ± 0% 589ns ± 0% -3.28% (p=0.000 n=10+10) FmtFprintfIntInt 938ns ± 0% 920ns ± 0% -1.92% (p=0.000 n=9+10) FmtFprintfPrefixedInt 950ns ± 0% 924ns ± 0% -2.72% (p=0.000 n=10+9) FmtFprintfFloat 1.41µs ± 1% 1.43µs ± 0% +1.01% (p=0.000 n=10+10) FmtManyArgs 3.66µs ± 1% 3.46µs ± 0% -5.43% (p=0.000 n=9+10) GobDecode 38.8ms ± 1% 37.8ms ± 0% -2.50% (p=0.000 n=10+8) GobEncode 26.3ms ± 1% 26.3ms ± 0% ~ (p=0.853 n=10+10) Gzip 1.16s ± 1% 1.16s ± 0% -0.37% (p=0.008 n=10+9) Gunzip 210ms ± 0% 208ms ± 1% -1.01% (p=0.000 n=10+10) JSONEncode 48.0ms ± 0% 48.1ms ± 1% +0.29% (p=0.019 n=9+9) JSONDecode 348ms ± 1% 326ms ± 1% -6.34% (p=0.000 n=10+10) Mandelbrot200 6.62ms ± 0% 6.64ms ± 0% +0.37% (p=0.000 n=7+9) GoParse 23.9ms ± 1% 24.7ms ± 1% +2.98% (p=0.000 n=9+9) RegexpMatchEasy0_32 555ns ± 0% 561ns ± 0% +1.10% (p=0.000 n=8+10) RegexpMatchEasy0_1K 3.94µs ± 1% 3.94µs ± 0% ~ (p=0.906 n=9+8) RegexpMatchEasy1_32 516ns ± 0% 524ns ± 0% +1.51% (p=0.000 n=9+10) RegexpMatchEasy1_1K 4.39µs ± 1% 4.40µs ± 1% ~ (p=0.171 n=10+10) RegexpMatchMedium_32 25.1ns ± 0% 25.5ns ± 0% +1.51% (p=0.000 n=9+8) RegexpMatchMedium_1K 196µs ± 0% 203µs ± 1% +3.23% (p=0.000 n=9+10) RegexpMatchHard_32 11.2µs ± 1% 11.6µs ± 1% +3.62% (p=0.000 n=10+10) RegexpMatchHard_1K 334µs ± 1% 348µs ± 1% +4.21% (p=0.000 n=9+10) Revcomp 2.39s ± 0% 2.41s ± 0% +0.78% (p=0.000 n=8+9) Template 385ms ± 1% 336ms ± 0% -12.61% (p=0.000 n=10+9) TimeParse 2.18µs ± 1% 2.18µs ± 1% ~ (p=0.424 n=10+10) TimeFormat 2.28µs ± 1% 2.22µs ± 1% -2.30% (p=0.000 n=10+10) name old speed new speed delta GobDecode 19.8MB/s ± 1% 20.3MB/s ± 0% +2.56% (p=0.000 n=10+8) GobEncode 29.1MB/s ± 1% 29.2MB/s ± 0% ~ (p=0.810 n=10+10) Gzip 16.7MB/s ± 1% 16.8MB/s ± 0% +0.37% (p=0.007 n=10+9) Gunzip 92.2MB/s ± 0% 93.2MB/s ± 1% +1.03% (p=0.000 n=10+10) JSONEncode 40.4MB/s ± 0% 40.3MB/s ± 1% -0.28% (p=0.025 n=9+9) JSONDecode 5.58MB/s ± 1% 5.96MB/s ± 1% +6.80% (p=0.000 n=10+10) GoParse 2.42MB/s ± 0% 2.35MB/s ± 1% -2.83% (p=0.000 n=8+9) RegexpMatchEasy0_32 57.7MB/s ± 0% 57.0MB/s ± 0% -1.09% (p=0.000 n=8+10) RegexpMatchEasy0_1K 260MB/s ± 1% 260MB/s ± 0% ~ (p=0.963 n=9+8) RegexpMatchEasy1_32 62.1MB/s ± 0% 61.1MB/s ± 0% -1.53% (p=0.000 n=10+10) RegexpMatchEasy1_1K 233MB/s ± 1% 233MB/s ± 1% ~ (p=0.190 n=10+10) RegexpMatchMedium_32 39.8MB/s ± 0% 39.1MB/s ± 1% -1.74% (p=0.000 n=9+10) RegexpMatchMedium_1K 5.21MB/s ± 0% 5.05MB/s ± 1% -3.09% (p=0.000 n=9+10) RegexpMatchHard_32 2.86MB/s ± 1% 2.76MB/s ± 1% -3.43% (p=0.000 n=10+10) RegexpMatchHard_1K 3.06MB/s ± 1% 2.94MB/s ± 1% -4.06% (p=0.000 n=9+10) Revcomp 106MB/s ± 0% 105MB/s ± 0% -0.77% (p=0.000 n=8+9) Template 5.04MB/s ± 1% 5.77MB/s ± 0% +14.48% (p=0.000 n=10+9) Updates #32591 Change-Id: Id567e14a788e359248b2129ef1cf0adc8cc4ab7f Reviewed-on: https://go-review.googlesource.com/c/go/+/183457 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Agniva De Sarker authored
When an invalid URL was passed to DumpRequestOut, it would directly return without gracefully shutting down the reader goroutine. So we create a channel and signal the reader goroutine to exit if an error occurs during roundtrip. Fixes #32571 Change-Id: I8c2970f1601e599f3d1ebfed298faf5f5716fc2c Reviewed-on: https://go-review.googlesource.com/c/go/+/182037 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Agniva De Sarker authored
Use the shiftIsBounded function to generate more efficient Shift instructions. Updates #25167 Change-Id: Id350f8462dc3a7ed3bfed0bcbea2860b8f40048a Reviewed-on: https://go-review.googlesource.com/c/go/+/182558 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Agniva De Sarker authored
Change-Id: I1b76daba90afd474390db8d9c238445abaac7ca6 Reviewed-on: https://go-review.googlesource.com/c/go/+/182557 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Sam Arnold authored
Run underscore validation only if we have seen underscores. Some performance results on my laptop: name old time/op new time/op delta Atof64Decimal-12 30.5ns ± 0% 23.8ns ± 0% -22.02% (p=0.016 n=5+4) Atof64Float-12 39.0ns ± 0% 28.7ns ± 0% -26.39% (p=0.002 n=6+6) Atof64FloatExp-12 64.4ns ± 1% 54.4ns ± 1% -15.65% (p=0.002 n=6+6) Atof64Big-12 115ns ± 1% 87ns ± 1% -24.45% (p=0.002 n=6+6) Atof64RandomBits-12 187ns ±14% 156ns ±19% -16.46% (p=0.032 n=6+6) Atof64RandomFloats-12 126ns ± 0% 105ns ± 1% -16.65% (p=0.000 n=6+5) Atof32Decimal-12 32.0ns ± 1% 24.0ns ± 1% -24.97% (p=0.002 n=6+6) Atof32Float-12 37.1ns ± 1% 27.0ns ± 1% -27.42% (p=0.002 n=6+6) Atof32FloatExp-12 68.4ns ± 1% 54.2ns ± 1% -20.77% (p=0.002 n=6+6) Atof32Random-12 92.0ns ± 1% 77.4ns ± 0% -15.81% (p=0.000 n=6+5) ParseInt/Pos/7bit-12 19.4ns ± 1% 13.8ns ±10% -28.94% (p=0.002 n=6+6) ParseInt/Pos/26bit-12 29.1ns ± 1% 19.8ns ± 2% -31.92% (p=0.002 n=6+6) ParseInt/Pos/31bit-12 33.1ns ± 0% 22.3ns ± 3% -32.62% (p=0.004 n=5+6) ParseInt/Pos/56bit-12 47.8ns ± 1% 30.7ns ± 1% -35.78% (p=0.004 n=6+5) ParseInt/Pos/63bit-12 51.9ns ± 1% 33.4ns ± 2% -35.49% (p=0.002 n=6+6) ParseInt/Neg/7bit-12 18.5ns ± 4% 13.4ns ± 3% -27.88% (p=0.002 n=6+6) ParseInt/Neg/26bit-12 28.4ns ± 3% 19.7ns ± 3% -30.38% (p=0.002 n=6+6) ParseInt/Neg/31bit-12 31.9ns ± 1% 21.8ns ± 2% -31.56% (p=0.002 n=6+6) ParseInt/Neg/56bit-12 46.2ns ± 0% 30.6ns ± 1% -33.73% (p=0.004 n=5+6) ParseInt/Neg/63bit-12 50.2ns ± 1% 33.2ns ± 1% -33.96% (p=0.002 n=6+6) Fixes #33330 Change-Id: I119da66457c2fbaf6e88bb90cf56417a16df8f0e Reviewed-on: https://go-review.googlesource.com/c/go/+/187957 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Ben Shi authored
This CL optimizes math.bits.TrailingZeros16 on 386 with a pair of BSFL and ORL instrcutions. The case TrailingZeros16-4 of the benchmark test in math/bits shows big improvement. name old time/op new time/op delta TrailingZeros16-4 1.55ns ± 1% 0.87ns ± 1% -43.87% (p=0.000 n=50+49) Change-Id: Ia899975b0e46f45dcd20223b713ed632bc32740b Reviewed-on: https://go-review.googlesource.com/c/go/+/189277 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ben Shi authored
This CL add test cases for the unary FP negative operation. Change-Id: I54e7292ca9df05da0c2b113adefc97ee1e94c6e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/190937 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ben Shi authored
This CL performs the branchelim optimization on WASM with its select instruction. And the total size of pkg/js_wasm decreased about 80KB by this optimization. Change-Id: I868eb146120a1cac5c4609c8e9ddb07e4da8a1d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/190957 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
fanzha02 authored
This patch supports the EL0 and EL1 system registers used in MRS/MSR instructions. This patch refactors the assembler code, allowing the assembler to read system register information from the automatically generated sysRegEnc.go file and move existing declared system registers to the sysRegEnc.go file. This patch adds 431 system registers, it is worth noting that the number of special registers is initialized to less than 1024 in the list7.go file. This CL also adds some test cases to test the newly added system registers. The test cases are contributed by Dianhong Xu <Dianhong.Xu@arm.com> Change-Id: Ic09a937eaaeefe82bd08b5dd726808f8ff6cebf6 Reviewed-on: https://go-review.googlesource.com/c/go/+/189577Reviewed-by:
Ben Shi <powerman1st@163.com> Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
We never used it, might as well get rid of it. Change-Id: I5c23c93e90173bff9ac1fc1b8ae1e2025215d6eb Reviewed-on: https://go-review.googlesource.com/c/go/+/191938 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 27 Aug, 2019 20 commits
-
-
Filippo Valsorda authored
Fixes #30055 Change-Id: If757c43b52fc7bf62b0afb1c720615329fb5569d Reviewed-on: https://go-review.googlesource.com/c/go/+/191999 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
SSLv3 has been irreparably broken since the POODLE attack 5 years ago and RFC 7568 (f.k.a. draft-ietf-tls-sslv3-diediedie) prohibits its use in no uncertain terms. As announced in the Go 1.13 release notes, remove support for it entirely in Go 1.14. Updates #32716 Change-Id: Id653557961d8f75f484a01e6afd2e104a4ccceaf Reviewed-on: https://go-review.googlesource.com/c/go/+/191976 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
While working on #30645, I noticed that many instances in which the walkinrange optimization could apply were not even being considered. This was because of extraneous blocks in the CFG, of the type that shortcircuit normally removes. The change improves the shortcircuit pass to handle most of those cases. (There are a few that can only be reasonably detected later in compilation, after other optimizations have been run, but not enough to be worth chasing.) Notable changes: * Instead of calculating live-across-blocks values, use v.Uses == 1. This is cheaper and more straightforward. v.Uses did not exist when this pass was initially written. * Incorporate a fusePlain and loop until stable. This is necessary to find many of the instances. * Allow Copy and Not wrappers around Phi values. This significantly increases effectiveness. * Allow removal of all preds, creating a dead block. The previous pass stopped unnecessarily at one pred. * Use phielimValue during cleanup instead of manually setting the op to OpCopy. The result is marginally faster compilation and smaller code. name old time/op new time/op delta Template 213ms ± 2% 212ms ± 2% -0.63% (p=0.002 n=49+48) Unicode 90.0ms ± 2% 89.8ms ± 2% ~ (p=0.122 n=48+48) GoTypes 710ms ± 3% 711ms ± 2% ~ (p=0.433 n=45+49) Compiler 3.23s ± 2% 3.22s ± 2% ~ (p=0.124 n=47+49) SSA 10.0s ± 1% 10.0s ± 1% -0.43% (p=0.000 n=48+50) Flate 135ms ± 3% 135ms ± 2% ~ (p=0.311 n=49+49) GoParser 158ms ± 2% 158ms ± 2% ~ (p=0.757 n=48+48) Reflect 447ms ± 2% 447ms ± 2% ~ (p=0.815 n=49+48) Tar 189ms ± 2% 189ms ± 3% ~ (p=0.530 n=47+49) XML 251ms ± 3% 250ms ± 1% -0.75% (p=0.002 n=49+48) [Geo mean] 427ms 426ms -0.25% name old user-time/op new user-time/op delta Template 265ms ± 2% 265ms ± 2% ~ (p=0.969 n=48+50) Unicode 119ms ± 6% 119ms ± 6% ~ (p=0.738 n=50+50) GoTypes 923ms ± 2% 925ms ± 2% ~ (p=0.057 n=43+47) Compiler 4.37s ± 2% 4.37s ± 2% ~ (p=0.691 n=50+46) SSA 13.4s ± 1% 13.4s ± 1% ~ (p=0.282 n=42+49) Flate 162ms ± 2% 162ms ± 2% ~ (p=0.774 n=48+50) GoParser 186ms ± 2% 186ms ± 3% ~ (p=0.213 n=47+47) Reflect 572ms ± 2% 573ms ± 3% ~ (p=0.303 n=50+49) Tar 240ms ± 3% 240ms ± 2% ~ (p=0.939 n=46+44) XML 302ms ± 2% 302ms ± 2% ~ (p=0.399 n=47+47) [Geo mean] 540ms 541ms +0.07% name old alloc/op new alloc/op delta Template 36.8MB ± 0% 36.7MB ± 0% -0.42% (p=0.008 n=5+5) Unicode 28.1MB ± 0% 28.1MB ± 0% ~ (p=0.151 n=5+5) GoTypes 124MB ± 0% 124MB ± 0% -0.26% (p=0.008 n=5+5) Compiler 571MB ± 0% 566MB ± 0% -0.84% (p=0.008 n=5+5) SSA 1.86GB ± 0% 1.85GB ± 0% -0.58% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.17% (p=0.008 n=5+5) GoParser 27.3MB ± 0% 27.3MB ± 0% -0.20% (p=0.008 n=5+5) Reflect 79.5MB ± 0% 79.3MB ± 0% -0.20% (p=0.008 n=5+5) Tar 34.7MB ± 0% 34.6MB ± 0% -0.42% (p=0.008 n=5+5) XML 45.4MB ± 0% 45.3MB ± 0% -0.29% (p=0.008 n=5+5) [Geo mean] 80.0MB 79.7MB -0.34% name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 0% -0.22% (p=0.008 n=5+5) Unicode 339k ± 0% 339k ± 0% ~ (p=0.643 n=5+5) GoTypes 1.36M ± 0% 1.36M ± 0% -0.10% (p=0.008 n=5+5) Compiler 5.51M ± 0% 5.50M ± 0% -0.13% (p=0.008 n=5+5) SSA 17.5M ± 0% 17.5M ± 0% -0.14% (p=0.008 n=5+5) Flate 234k ± 0% 234k ± 0% -0.04% (p=0.008 n=5+5) GoParser 299k ± 0% 299k ± 0% -0.05% (p=0.008 n=5+5) Reflect 978k ± 0% 979k ± 0% +0.02% (p=0.016 n=5+5) Tar 351k ± 0% 351k ± 0% -0.04% (p=0.008 n=5+5) XML 435k ± 0% 435k ± 0% -0.11% (p=0.008 n=5+5) [Geo mean] 840k 840k -0.08% file before after Δ % go 14794788 14770212 -24576 -0.166% addr2line 4203688 4199592 -4096 -0.097% api 5954056 5941768 -12288 -0.206% asm 4862704 4846320 -16384 -0.337% cgo 4778920 4770728 -8192 -0.171% compile 24001568 23923792 -77776 -0.324% cover 5198440 5190248 -8192 -0.158% dist 3595248 3587056 -8192 -0.228% doc 4618504 4610312 -8192 -0.177% fix 3337416 3333320 -4096 -0.123% link 6120408 6116312 -4096 -0.067% nm 4149064 4140872 -8192 -0.197% objdump 4555608 4547416 -8192 -0.180% pprof 14616324 14595844 -20480 -0.140% test2json 2766328 2762232 -4096 -0.148% trace 11638844 11622460 -16384 -0.141% vet 8274936 8258552 -16384 -0.198% total 132520780 132270972 -249808 -0.189% Change-Id: Ifcd235a2a6e5f13ed5c93e62523e2ef61321fccf Reviewed-on: https://go-review.googlesource.com/c/go/+/178197 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
'git ls-remote' started recognizing the '--' separator at some point after 2.7.4, but git defaults to version 2.7.4 on Ubuntu 16.04 LTS, which remains supported by Ubuntu until April 2021. We added '--' tokens to most VCS commands as a defensive measure in CL 181237, but it isn't strictly necessary here because the 'scheme' argument to our template is chosen from a predefined list: we can safely drop it to retain compatibility. Fixes #33836 Updates #26746 Change-Id: Ibb53366b95f8029b587e0b7646a439330d759ac7 Reviewed-on: https://go-review.googlesource.com/c/go/+/191978 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitri Shuralyov <dmitshur@golang.org>
-
Josh Bleecher Snyder authored
CSE can make dead values live again. Running deadcode first avoids that; it also makes CSE more efficient. file before after Δ % api 5970616 5966520 -4096 -0.069% asm 4867088 4846608 -20480 -0.421% compile 23988320 23935072 -53248 -0.222% link 6084376 6080280 -4096 -0.067% nm 4165736 4161640 -4096 -0.098% objdump 4572216 4568120 -4096 -0.090% pprof 14452996 14457092 +4096 +0.028% trace 11467292 11471388 +4096 +0.036% total 132181100 132099180 -81920 -0.062% Compiler performance impact is negligible: name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.8MB ± 0% -0.04% (p=0.008 n=5+5) Unicode 28.2MB ± 0% 28.2MB ± 0% ~ (p=1.000 n=5+5) GoTypes 131MB ± 0% 131MB ± 0% -0.14% (p=0.008 n=5+5) Compiler 606MB ± 0% 606MB ± 0% -0.05% (p=0.008 n=5+5) SSA 2.14GB ± 0% 2.13GB ± 0% -0.26% (p=0.008 n=5+5) Flate 24.0MB ± 0% 24.0MB ± 0% -0.18% (p=0.008 n=5+5) GoParser 28.8MB ± 0% 28.8MB ± 0% -0.15% (p=0.008 n=5+5) Reflect 83.8MB ± 0% 83.7MB ± 0% -0.11% (p=0.008 n=5+5) Tar 36.4MB ± 0% 36.4MB ± 0% -0.09% (p=0.008 n=5+5) XML 47.9MB ± 0% 47.8MB ± 0% -0.15% (p=0.008 n=5+5) [Geo mean] 84.6MB 84.5MB -0.12% name old allocs/op new allocs/op delta Template 379k ± 0% 380k ± 0% +0.15% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% ~ (p=0.738 n=5+5) GoTypes 1.36M ± 0% 1.36M ± 0% +0.05% (p=0.008 n=5+5) Compiler 5.49M ± 0% 5.49M ± 0% +0.12% (p=0.008 n=5+5) SSA 17.5M ± 0% 17.5M ± 0% -0.18% (p=0.008 n=5+5) Flate 235k ± 0% 235k ± 0% ~ (p=0.079 n=5+5) GoParser 302k ± 0% 302k ± 0% ~ (p=0.310 n=5+5) Reflect 976k ± 0% 977k ± 0% +0.08% (p=0.008 n=5+5) Tar 352k ± 0% 352k ± 0% +0.12% (p=0.008 n=5+5) XML 436k ± 0% 436k ± 0% -0.05% (p=0.008 n=5+5) [Geo mean] 842k 842k +0.03% Change-Id: I53e8faed1859885ca5c4a5d45067a50984f3eff1 Reviewed-on: https://go-review.googlesource.com/c/go/+/175879 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Stefan Baebler authored
The TestParseErrors test function was not strict with unwanted errors received from url.Parse(). It was not failing in such cases, now it does Fixes #33646 Updates #29098 Change-Id: I069521093e2bff8b1fcd41ffd3f9799f3108bc61 GitHub-Last-Rev: e6844c57f979ddb8418643d9c5244a5d1b4578ba GitHub-Pull-Request: golang/go#33876 Reviewed-on: https://go-review.googlesource.com/c/go/+/191966 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Filippo Valsorda <filippo@golang.org>
-
Anderson Queiroz authored
Fixes golang/go#31249 Change-Id: I3280f8ab170ed31d4efb71106533e016d430d44c Reviewed-on: https://go-review.googlesource.com/c/go/+/191557Reviewed-by:
-
Filippo Valsorda authored
It was mistakenly re-enabled in CL 146217. Fixes #33837 Change-Id: I8c0e1787114c6232df5888e51e355906622295bc Reviewed-on: https://go-review.googlesource.com/c/go/+/191877 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
Updates #33879 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/191997 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by:
Alexander Rakoczy <alex@golang.org>
-
Matthew Dempsky authored
Because the Node AST represents references to declared objects (e.g., variables, packages, types, constants) by directly pointing to the referred object, we don't have use-position info for these objects. For switch statements with duplicate cases, we report back where the first duplicate value appeared. However, due to the AST representation, if the value was a declared constant, we mistakenly reported the constant declaration position as the previous case position. This CL reports back against the 'case' keyword's position instead, if there's no more precise information available to us. It also refactors code to emit the same "previous at" error message for duplicate values in map literals. Thanks to Emmanuel Odeke for the test case. Fixes #33460. Change-Id: Iec69542ccd4aad594dde8df02d1b880a422c5622 Reviewed-on: https://go-review.googlesource.com/c/go/+/188901Reviewed-by:
-
Matthew Dempsky authored
Use efaceOf to safely convert from *interface{} to *_eface, and to make it clearer what the pointer arithmetic is computing. Incidentally, remove a spurious unsafe.Pointer->*uint8->unsafe.Pointer round trip conversion in newproc. No behavior change. Change-Id: I2ad9d791d35d8bd008ef43b03dad1589713c5fd4 Reviewed-on: https://go-review.googlesource.com/c/go/+/190457 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Bryan C. Mills authored
I'm trying to keep the code changes minimal for backporting to Go 1.13, so it is still possible for a handful of entries to leak, but the leaks are now O(1) instead of O(N) in the steady state. Longer-term, I think it would be a good idea to coalesce idleMu with connsPerHostMu and clear entries out of both queues as soon as their goroutines are done waiting. Fixes #33849 Fixes #33850 Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281 Reviewed-on: https://go-review.googlesource.com/c/go/+/191964 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
LE Manh Cuong authored
The assembly output for x & c == c, where c is power of 2: MOVQ "".set+8(SP), AX ANDQ $8, AX CMPQ AX, $8 SETEQ "".~r2+24(SP) With optimization using bitset: MOVQ "".set+8(SP), AX BTL $3, AX SETCS "".~r2+24(SP) output less than 1 instruction. However, there is no speed improvement: name old time/op new time/op delta AllBitSet-8 0.35ns ± 0% 0.35ns ± 0% ~ (all equal) Fixes #31904 Change-Id: I5dca4e410bf45716ed2145e3473979ec997e35d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/175957 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
The decoder called this function to check numbers being decoded into a json.Number. However, these can't be quoted as strings, so the tokenizer has already verified they are valid JSON numbers. Verified this by adding a test with such an input. As expected, it produces a syntax error, not the fmt.Errorf - that line could never execute. Since the only remaining non-test caller of isvalidnumber is in encode.go, move the function there. This change should slightly reduce the amount of work when decoding into json.Number, though that isn't very common nor part of any current benchmarks. Change-Id: I67a1723deb3d18d5b542d6dd35f3ae56a43f23eb Reviewed-on: https://go-review.googlesource.com/c/go/+/184817 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Dong-hee Na authored
There is an unnecessary lower operation in isJSType. Simple logic fix can improve tiny performance. name old time/op new time/op delta isJSType-8 152ns ± 0% 58ns ± 7% -61.82% (p=0.001 n=6+8) name old alloc/op new alloc/op delta isJSType-8 32.0B ± 0% 0.0B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta isJSType-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) Change-Id: I281aadf1677d4377920c9649af206381189a27e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/177118 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
This reverts https://golang.org/cl/185080. Reason for revert: some new changes are erroring again, so this broke the builders. Change-Id: I28da16da98b90cefbb47173d31bbbb56e43062d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/191781 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
LE Manh Cuong authored
state and ssafn both have their own Fatalf, so use them instead of global Fatalf. Updates #19683 Change-Id: Ie02a961d4285ab0a3f3b8d889a5b498d926ed567 Reviewed-on: https://go-review.googlesource.com/c/go/+/188539 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
First, add cpu and memory profiling flags, as these are useful to see where rulegen is spending its time. It now takes many seconds to run on a recent laptop, so we have to keep an eye on what it's doing. Second, stop writing '_ = var' lines to keep imports and variables used at all times. Now that rulegen removes all such unused names, they're unnecessary. To perform the removal, lean on go/types to first detect what names are unused. We can configure it to give us all the type-checking errors in a file, so we can collect all "declared but not used" errors in a single pass. We then use astutil.Apply to remove the relevant nodes based on the line information from each unused error. This allows us to apply the changes without having to do extra parser+printer roundtrips to plaintext, which are far too expensive. We need to do multiple such passes, as removing an unused variable declaration might then make another declaration unused. Two passes are enough to clean every file at the moment, so add a limit of three passes for now to avoid eating cpu uncontrollably by accident. The resulting performance of the changes above is a ~30% loss across the table, since go/types is fairly expensive. The numbers were obtained with 'benchcmd Rulegen go run *.go', which involves compiling rulegen itself, but that seems reflective of how the program is used. name old time/op new time/op delta Rulegen 5.61s ± 0% 7.36s ± 0% +31.17% (p=0.016 n=5+4) name old user-time/op new user-time/op delta Rulegen 7.20s ± 1% 9.92s ± 1% +37.76% (p=0.016 n=5+4) name old sys-time/op new sys-time/op delta Rulegen 135ms ±19% 169ms ±17% +25.66% (p=0.032 n=5+5) name old peak-RSS-bytes new peak-RSS-bytes delta Rulegen 71.0MB ± 2% 85.6MB ± 2% +20.56% (p=0.008 n=5+5) We can live with a bit more resource usage, but the time/op getting close to 10s isn't good. To win that back, introduce concurrency in main.go. This further increases resource usage a bit, but the real time on this quad-core laptop is greatly reduced. The final benchstat is as follows: name old time/op new time/op delta Rulegen 5.61s ± 0% 3.97s ± 1% -29.26% (p=0.008 n=5+5) name old user-time/op new user-time/op delta Rulegen 7.20s ± 1% 13.91s ± 1% +93.09% (p=0.008 n=5+5) name old sys-time/op new sys-time/op delta Rulegen 135ms ±19% 269ms ± 9% +99.17% (p=0.008 n=5+5) name old peak-RSS-bytes new peak-RSS-bytes delta Rulegen 71.0MB ± 2% 226.3MB ± 1% +218.72% (p=0.008 n=5+5) It might be possible to reduce the cpu or memory usage in the future, such as configuring go/types to do less work, or taking shortcuts to avoid having to run it many times. For now, ~2x cpu and ~4x memory usage seems like a fair trade for a faster and better rulegen. Finally, we can remove the old code that tried to remove some unused variables in a hacky and unmaintainable way. Change-Id: Iff9e83e3f253babf5a1bd48cc993033b8550cee6 Reviewed-on: https://go-review.googlesource.com/c/go/+/189798 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Andrew Gerrand authored
This removes a special case that was added to fix issue #10956, but that was never actually effective. The code in the test case still fails to read, so perhaps the zip64 support added in CL 6463050 inadvertently caught this particular case. It's possible that the original theorized bug still exists, but I'm not convinced it was ever fixed. Update #28700 Change-Id: I4854de616364510f64a6def30b308686563f8dbb Reviewed-on: https://go-review.googlesource.com/c/go/+/179757 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
tnclong authored
Template.New calls t.init, which allocates several items that are immediately rewritten by copy, so avoid the call to New Change-Id: I16c7cb001bbcd14cf547c1a2db2734a2f8214e7e Reviewed-on: https://go-review.googlesource.com/c/go/+/182757 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
