- 02 Nov, 2018 17 commits
-
-
Dmitry Vyukov authored
We only need the memory barrier from these stores, and we only store nil over nil or over a static function value. The write barrier is unnecessary. name old time/op new time/op delta TCP4OneShotTimeout-6 17.0µs ± 0% 17.0µs ± 0% -0.43% (p=0.032 n=5+5) SetReadDeadline-6 205ns ± 1% 205ns ± 1% ~ (p=0.683 n=5+5) Update #25729 Change-Id: I66c097a1db7188697ddfc381f31acec053dfed2c Reviewed-on: https://go-review.googlesource.com/c/146345 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Tobias Klauser authored
Follow CL 146020 and enable RemoveAll based on Unlinkat and Openat on aix. Updates #27029 Change-Id: I78b34ed671166ee6fa651d5f2025b88548ee6c68 Reviewed-on: https://go-review.googlesource.com/c/146937 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
Clément Chigot <clement.chigot@atos.net> Reviewed-by:
-
Dmitry Vyukov authored
runtimeNano is slower than nanotime, so pass the duration to runtime_pollSetDeadline as is. netpoll can add nanotime itself. Arguably a bit simpler because, say, a negative duration clearly represents already expired timer, no need to compare to nanotime again. This may also fix an obscure corner case when a deadline in past which happens to be nanotime 0 is confused with no deadline at all, which are radically different things. Also don't compute any durations and times if Time is zero (currently we first compute everything and then reset d back to 0, which is wasteful). name old time/op new time/op delta TCP4OneShotTimeout-6 17.1µs ± 0% 17.0µs ± 0% ~ (p=0.421 n=5+5) SetReadDeadline-6 230ns ± 0% 205ns ± 1% -10.63% (p=0.008 n=5+5) Change-Id: I2aad699270289a5b9ead68f5e44ec4ec6d96baa0 Reviewed-on: https://go-review.googlesource.com/c/146344Reviewed-by:
-
Dmitry Vyukov authored
We only need the memory barrier in poll_runtime_pollSetDeadline only when one of the timers has fired, which is not the expected case. Memory barrier can be somewhat expensive on some archs, so execute it only if one of the timers has in fact fired. name old time/op new time/op delta TCP4OneShotTimeout-6 17.0µs ± 0% 17.1µs ± 0% +0.35% (p=0.032 n=5+5) SetReadDeadline-6 232ns ± 0% 230ns ± 0% -1.03% (p=0.000 n=4+5) Update #25729 Change-Id: Ifce6f505b9e7ba3717bad8f454077a2e94ea6e75 Reviewed-on: https://go-review.googlesource.com/c/146343Reviewed-by:
-
Dmitry Vyukov authored
The nanotime wrappers in runtime introduce a bunch of unnecessary code onto hot paths, e.g.: 0000000000449d70 <time.runtimeNano>: 449d70: 64 48 8b 0c 25 f8 ff mov %fs:0xfffffffffffffff8,%rcx 449d77: ff ff 449d79: 48 3b 61 10 cmp 0x10(%rcx),%rsp 449d7d: 76 26 jbe 449da5 <time.runtimeNano+0x35> 449d7f: 48 83 ec 10 sub $0x10,%rsp 449d83: 48 89 6c 24 08 mov %rbp,0x8(%rsp) 449d88: 48 8d 6c 24 08 lea 0x8(%rsp),%rbp 449d8d: e8 ae 18 01 00 callq 45b640 <runtime.nanotime> 449d92: 48 8b 04 24 mov (%rsp),%rax 449d96: 48 89 44 24 18 mov %rax,0x18(%rsp) 449d9b: 48 8b 6c 24 08 mov 0x8(%rsp),%rbp 449da0: 48 83 c4 10 add $0x10,%rsp 449da4: c3 retq 449da5: e8 56 e0 00 00 callq 457e00 <runtime.morestack_noctxt> 449daa: eb c4 jmp 449d70 <time.runtimeNano> Move them to the corresponding packages which eliminates all of this. name old time/op new time/op delta TCP4OneShotTimeout-6 17.1µs ± 1% 17.0µs ± 0% -0.66% (p=0.032 n=5+5) SetReadDeadline-6 234ns ± 1% 232ns ± 0% -0.77% (p=0.016 n=5+4) Update #25729 Change-Id: Iee05027adcdc289ba895c5f5a37f154e451bc862 Reviewed-on: https://go-review.googlesource.com/c/146342 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Dmitry Vyukov authored
time.now is somewhat expensive (much more expensive than nanotime), in the common case when Time has monotonic time we don't actually need to call time.now in Since/Until as we can do calculation based purely on monotonic times. name old time/op new time/op delta TCP4OneShotTimeout-6 17.0µs ± 0% 17.1µs ± 1% ~ (p=0.151 n=5+5) SetReadDeadline-6 261ns ± 0% 234ns ± 1% -10.35% (p=0.008 n=5+5) Benchmark that only calls Until: benchmark old ns/op new ns/op delta BenchmarkUntil 54.0 29.5 -45.37% Update #25729 Change-Id: I5ac5af3eb1fe9f583cf79299f10b84501b1a0d7d Reviewed-on: https://go-review.googlesource.com/c/146341 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
-
Dmitry Vyukov authored
Move startNano from runtime to time package. In preparation for a subsequent change that speeds up Since and Until. This also makes code simpler as we have less assembly as the result, monotonic time handling is better localized in time package. This changes values returned from nanotime on windows (it does not account for startNano anymore), current comments state that it's important, but it's unclear how it can be important since no other OS does this. Update #25729 Change-Id: I2275d57b7b5ed8fd0d53eb0f19d55a86136cc555 Reviewed-on: https://go-review.googlesource.com/c/146340Reviewed-by:
-
Dmitry Vyukov authored
Currently when netpoll deadline is incrementally prolonged, we delete and re-add timer each time. Add modtimer function that does both and use it when we need to modify an existing netpoll timer to avoid unnecessary lock/unlock. TCP4OneShotTimeout-6 17.2µs ± 0% 17.0µs ± 0% -0.82% (p=0.008 n=5+5) SetReadDeadline-6 274ns ± 2% 261ns ± 0% -4.89% (p=0.008 n=5+5) Update #25729 Change-Id: I08b89dbbc1785dd180e967a37b0aa23b0c4613a8 Reviewed-on: https://go-review.googlesource.com/c/146339Reviewed-by:
-
Dmitry Vyukov authored
Currently we always delete both read and write timers and then add them again. However, if user setups read and write deadline separately, then we don't need to touch the other one. name old time/op new time/op delta TCP4OneShotTimeout-6 17.2µs ± 0% 17.2µs ± 0% ~ (p=0.310 n=5+5) SetReadDeadline-6 319ns ± 1% 274ns ± 2% -13.94% (p=0.008 n=5+5) Update #25729 Change-Id: I4c869c3083521de6d0cd6ca99a7609d4dd84b4e4 Reviewed-on: https://go-review.googlesource.com/c/146338Reviewed-by:
-
Dmitry Vyukov authored
It's not always necessary to wake timerproc even if we add a new timer to the top of the heap. Since we don't wake and reset timerproc when we remove timers, it still can be sleeping with shorter timeout. It such case it's more profitable to let it sleep and then update timeout when it wakes on its own rather than proactively wake it, let it update timeout and go to sleep again. name old time/op new time/op delta TCP4OneShotTimeout-6 18.6µs ± 1% 17.2µs ± 0% -7.66% (p=0.008 n=5+5) SetReadDeadline-6 562ns ± 5% 319ns ± 1% -43.27% (p=0.008 n=5+5) Update #25729 Change-Id: Iec8eacb8563dbc574a82358b3bac7ac479c16826 Reviewed-on: https://go-review.googlesource.com/c/146337Reviewed-by:
-
Michael Munday authored
This change uses library functions such as bits.RotateLeft32 to reduce the amount of code needed in the generic implementation. Since the code is now shorter I've also removed the option to generate a non-unrolled version of the code. I've also tried to remove bounds checks where possible to make the new version performant, however that is not the primary goal of this change since most architectures have assembly implementations already. Assembly performance: name old speed new speed delta Hash8Bytes 50.3MB/s ± 1% 59.1MB/s ± 0% +17.63% (p=0.000 n=9+8) Hash1K 590MB/s ± 0% 597MB/s ± 0% +1.25% (p=0.000 n=9+9) Hash8K 636MB/s ± 1% 638MB/s ± 1% ~ (p=0.072 n=10+10) Hash8BytesUnaligned 50.5MB/s ± 0% 59.1MB/s ± 1% +17.09% (p=0.000 n=10+10) Hash1KUnaligned 589MB/s ± 1% 596MB/s ± 1% +1.23% (p=0.000 n=9+10) Hash8KUnaligned 638MB/s ± 1% 640MB/s ± 0% +0.35% (p=0.002 n=10+10) Pure Go performance: name old speed new speed delta Hash8Bytes 30.3MB/s ± 1% 42.8MB/s ± 0% +41.20% (p=0.000 n=9+9) Hash1K 364MB/s ± 4% 394MB/s ± 1% +8.27% (p=0.000 n=10+10) Hash8K 404MB/s ± 1% 420MB/s ± 0% +4.17% (p=0.000 n=10+9) Hash8BytesUnaligned 30.3MB/s ± 1% 42.8MB/s ± 1% +40.92% (p=0.000 n=9+10) Hash1KUnaligned 368MB/s ± 0% 394MB/s ± 0% +7.07% (p=0.000 n=9+9) Hash8KUnaligned 404MB/s ± 1% 411MB/s ± 3% +1.91% (p=0.026 n=9+10) Change-Id: I9a91fb52ea8d62964d5351bdf121e9fbc9282852 Reviewed-on: https://go-review.googlesource.com/c/137355 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Brainman authored
Stat uses Windows FindFirstFile + CreateFile to gather symlink information - FindFirstFile determines if file is a symlink, and then CreateFile follows symlink to capture target details. Lstat only uses FindFirstFile. This CL replaces current approach with just a call to CreateFile. Lstat uses FILE_FLAG_OPEN_REPARSE_POINT flag, that instructs CreateFile not to follow symlink. Other than that both Stat and Lstat look the same now. New code is simpler. CreateFile + GetFileInformationByHandle (unlike FindFirstFile) does not report reparse tag of a file. I tried to ignore reparse tag altogether. And it works for symlinks and mount points. Unfortunately (see https://github.com/moby/moby/issues/37026), files on deduped disk volumes are reported with FILE_ATTRIBUTE_REPARSE_POINT attribute set and reparse tag set to IO_REPARSE_TAG_DEDUP. So, if we ignore reparse tag, Lstat interprets deduped volume files as symlinks. That is incorrect. So I had to add GetFileInformationByHandleEx call to gather reparse tag after calling CreateFile and GetFileInformationByHandle. Fixes #27225 Fixes #27515 Change-Id: If60233bcf18836c147597cc17450d82f3f88c623 Reviewed-on: https://go-review.googlesource.com/c/143578 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Kirill Kolyshkin <kolyshkin@gmail.com>
-
Alex Brainman authored
This CL changes IsAbs to return true for "NUL" and other Windows reserved filenames (search https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file for NUL for details). os.Open("NUL") and os.Stat("NUL") work regardless of what current directory is, and it is mistake to join "NUL" with current directory when building full path. Changing IsAbs("NUL") to return true fixes that mistake. Fixes #28035 Change-Id: Ife8f8aee48400702613ede8fc6834fd43e6e0f03 Reviewed-on: https://go-review.googlesource.com/c/145220 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Updating each call in place broke when there were multiple cgo calls used as arguments to another cgo call where some required rewriting. Instead, rewrite calls to strings via the existing mangling mechanism, and only substitute the top level call in place. Fixes #28540 Change-Id: Ifd66f04c205adc4ad6dd5ee8e79e57dce17e86bb Reviewed-on: https://go-review.googlesource.com/c/146860Reviewed-by:
Dmitri Shuralyov <dmitshur@golang.org>
-
Dmitri Shuralyov authored
Fixes #27914 Change-Id: Ic359a099661e959eb25d0f763ea16a6f48a3d4c7 Reviewed-on: https://go-review.googlesource.com/c/138295Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Martin Möhrmann authored
As discussed in golang.org/cl/28499: Only test that all expected variables are listed in 'info locals' since different versions of gdb print variables in different order and with differing amount of information and formats. Fixes #28499 Change-Id: I76627351170b5fdf2bf8cbf143e54f628b45dc4e Reviewed-on: https://go-review.googlesource.com/c/146598Reviewed-by:
Heschi Kreinick <heschi@google.com>
-
Alan Donovan authored
For many build systems, modular static analysis is most conveniently implemented by saving analysis facts (which are analogous to export data) in an additional section in the archive file, similar to __PKGDEF. See golang.org/x/tools/go/analysis for an overview. Because such sections are not object files, the linker must not attempt to link them. This change causes the linker to skip special sections whose name does not end with .o (and is short enough not to be truncated). Fixes #28429 Change-Id: I830852decf868cb017263308b114f72838032993 Reviewed-on: https://go-review.googlesource.com/c/146297 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 01 Nov, 2018 10 commits
-
-
Ian Lance Taylor authored
Fixes #14210 Fixes #25941 Change-Id: Idde2d032290da3edb742b5b4f6ffeb625f05b494 Reviewed-on: https://go-review.googlesource.com/c/142884Reviewed-by:
-
Andrew Bonventre authored
Change-Id: I9cb3c80ea397d964fe745b74d595df3fd8982a47 Reviewed-on: https://go-review.googlesource.com/c/146257Reviewed-by:
-
Tobias Klauser authored
Follow CL 146020 and enable RemoveAll based on Unlinkat and Openat on freebsd. Since the layout of syscall.Stat_t changes in FreeBSD 12, Fstatat needs a compatibility wrapper akin to Fstatat in x/sys/unix. See CL 138595 and CL 136816 for details. Updates #27029 Change-Id: I8851a5b7fa658eaa6e69a1693150b16d9a68f36a Reviewed-on: https://go-review.googlesource.com/c/146597 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Yuval Pavel Zholkover <paulzhol@gmail.com> Reviewed-by:
-
Brad Fitzpatrick authored
The Dialer.DualStack field is now meaningless and documented as deprecated. To disable fallback, set FallbackDelay to a negative value. Fixes #22225 Change-Id: Icc212fe07bb69d7651ab81e539b8b3e3d3372fa9 Reviewed-on: https://go-review.googlesource.com/c/146659Reviewed-by:
-
Carlos Eduardo Seo authored
This change adds asm implementations of xorBytes for ppc64x that takes advantage of VSX registers and instructions. name old time/op new time/op delta XORBytes/8Bytes-8 16.4ns ± 0% 11.1ns ± 0% -32.32% (p=0.000 n=5+4) XORBytes/128Bytes-8 45.6ns ± 0% 16.2ns ± 0% -64.50% (p=0.008 n=5+5) XORBytes/2048Bytes-8 433ns ±13% 129ns ± 1% -70.29% (p=0.000 n=5+4) XORBytes/32768Bytes-8 7.16µs ± 0% 1.83µs ± 0% -74.39% (p=0.008 n=5+5) name old speed new speed delta XORBytes/8Bytes-8 488MB/s ± 0% 721MB/s ± 0% +47.75% (p=0.016 n=5+4) XORBytes/128Bytes-8 2.80GB/s ± 0% 7.89GB/s ± 0% +181.33% (p=0.008 n=5+5) XORBytes/2048Bytes-8 4.77GB/s ±13% 15.87GB/s ± 0% +232.68% (p=0.016 n=5+4) XORBytes/32768Bytes-8 4.58GB/s ± 0% 17.88GB/s ± 0% +290.47% (p=0.008 n=5+5) Change-Id: Ic27d9b858f8ec2d597fdabc68a288d6844eba701 Reviewed-on: https://go-review.googlesource.com/c/145997 Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com>
-
Travis Bischel authored
readContinuedLineSlice intends to buffer a continued line of text, where a continued line can continue through newlines so long as the next line begins with a space or tab. The current optimization is to not try to buffer and build a line if we immediately see that the next line begins with an ASCII character. This adds avoiding copying the line if we see that the next line is \n or \r\n as well. Notably, headers always end in \r\n\r\n. In the general, well formatted header case, we can now avoid ever allocating textproto.Reader's internal reusable buf. This can mildly be seen in net/http's BenchmarkClientServer: name old time/op new time/op delta ClientServer-4 66.4µs ± 0% 66.2µs ± 0% -0.35% (p=0.004 n=10+10) name old alloc/op new alloc/op delta ClientServer-4 4.87kB ± 0% 4.82kB ± 0% -1.01% (p=0.000 n=6+10) name old allocs/op new allocs/op delta ClientServer-4 64.0 ± 0% 63.0 ± 0% -1.56% (p=0.000 n=10+10) Change-Id: Id8c2ab69086ac481b90abda289396dcb7bfe8851 Reviewed-on: https://go-review.googlesource.com/c/134227Reviewed-by:
-
tkivisik authored
Previous wording was incorrect. Change-Id: I91406c775161d9724ec60824c156e8e9a925bcd7 GitHub-Last-Rev: 2b6b4e136a78a431cc847a2717cbeae4341ed7bc GitHub-Pull-Request: golang/go#28248 Reviewed-on: https://go-review.googlesource.com/c/142879Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
Austin Clements authored
Change-Id: Id14b417095628c7a1dc7a8e47bc28cfa392b5262 Reviewed-on: https://go-review.googlesource.com/c/146498Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
Also, use a random temporary directory rather than os.TempDir. Defer removal of existing random temporary directories. Change-Id: Id7549031cdf78a2bab28c07b6eeff621bdf6e49c Reviewed-on: https://go-review.googlesource.com/c/146457 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Tobias Klauser <tobias.klauser@gmail.com>
-
Austin Clements authored
I don't know how this file wasn't gofmted. Change-Id: I9b3765ae63970b7bc4dc87107f546e64a78e2830 Reviewed-on: https://go-review.googlesource.com/c/146497Reviewed-by:
-
- 31 Oct, 2018 13 commits
-
-
Keith Randall authored
Divide the "empty" slot state into two, "emptyOne" and "emptyRest". emptyOne means just that slot is empty. emptyRest means all subsequent slots in that bucket are empty and the overflow pointer is nil. When scanning a bucket, we can often stop at emptyRest, reducing the total work we have to do. (This is similar to how tombstones work in open addressing.) Ideally on delete we have to figure out whether to zero the slot with an emptyOne or emptyRest marker. For now, we choose the safe but non-optimal choice. (Fix in subsequent CL?) This is a simpler CL than some others we've tried, including my CL sequence 11835[5-8] and Ilya's CL 115616. Update #19495 name old time/op new time/op delta MegMap 8.96ns ± 2% 8.74ns ± 6% -2.44% (p=0.020 n=10+10) MegOneMap 8.91ns ± 2% 5.53ns ± 2% -37.99% (p=0.000 n=10+10) MegEqMap 46.0µs ± 1% 45.8µs ± 3% ~ (p=0.315 n=9+10) MegEmptyMap 2.50ns ± 0% 2.50ns ± 2% ~ (p=0.957 n=8+10) SmallStrMap 8.54ns ± 1% 8.71ns ± 2% +2.01% (p=0.000 n=10+10) MapStringKeysEight_16 8.61ns ± 3% 8.71ns ± 3% +1.20% (p=0.026 n=9+9) MapStringKeysEight_32 8.54ns ± 2% 8.97ns ± 1% +5.05% (p=0.000 n=10+9) MapStringKeysEight_64 8.66ns ± 2% 8.99ns ± 2% +3.87% (p=0.000 n=10+10) MapStringKeysEight_1M 8.57ns ± 2% 8.95ns ± 2% +4.51% (p=0.000 n=10+9) IntMap 6.69ns ± 1% 7.46ns ± 1% +11.60% (p=0.000 n=9+9) MapFirst/1 3.69ns ± 1% 3.63ns ± 3% -1.52% (p=0.040 n=10+10) MapFirst/2 3.70ns ± 2% 3.63ns ± 2% -1.95% (p=0.001 n=9+9) MapFirst/3 3.74ns ± 2% 3.66ns ± 2% -2.12% (p=0.000 n=8+10) MapFirst/4 3.71ns ± 2% 3.66ns ± 4% ~ (p=0.073 n=9+10) MapFirst/5 3.69ns ± 1% 3.62ns ± 2% -1.88% (p=0.000 n=9+10) MapFirst/6 3.68ns ± 2% 3.62ns ± 1% -1.83% (p=0.001 n=10+9) MapFirst/7 3.67ns ± 1% 3.60ns ± 1% -1.98% (p=0.000 n=10+8) MapFirst/8 3.68ns ± 2% 3.61ns ± 2% -1.87% (p=0.000 n=10+10) MapFirst/9 8.03ns ± 4% 7.89ns ± 2% -1.76% (p=0.007 n=10+10) MapFirst/10 7.99ns ± 2% 7.86ns ± 3% -1.64% (p=0.009 n=9+10) MapFirst/11 7.96ns ± 1% 7.80ns ± 2% -2.01% (p=0.000 n=10+10) MapFirst/12 7.96ns ± 1% 7.82ns ± 1% -1.67% (p=0.000 n=10+10) MapFirst/13 8.06ns ± 3% 7.92ns ± 3% ~ (p=0.055 n=10+10) MapFirst/14 7.95ns ± 1% 7.80ns ± 1% -1.88% (p=0.000 n=10+9) MapFirst/15 8.01ns ± 2% 7.80ns ± 2% -2.57% (p=0.000 n=10+10) MapFirst/16 8.05ns ± 2% 7.90ns ± 2% -1.84% (p=0.005 n=9+10) MapMid/1 4.00ns ± 1% 3.94ns ± 2% -1.30% (p=0.021 n=8+9) MapMid/2 4.39ns ± 2% 4.32ns ± 4% ~ (p=0.128 n=10+10) MapMid/3 4.40ns ± 2% 4.27ns ± 2% -2.93% (p=0.000 n=10+9) MapMid/4 4.76ns ± 2% 4.65ns ± 1% -2.26% (p=0.000 n=10+9) MapMid/5 4.76ns ± 1% 4.65ns ± 1% -2.27% (p=0.000 n=10+10) MapMid/6 5.11ns ± 2% 4.98ns ± 2% -2.55% (p=0.000 n=10+10) MapMid/7 5.12ns ± 1% 5.01ns ± 3% -2.02% (p=0.003 n=9+9) MapMid/8 5.71ns ± 3% 5.97ns ± 1% +4.51% (p=0.000 n=10+9) MapMid/9 8.72ns ±10% 8.89ns ±10% ~ (p=0.458 n=9+10) MapMid/10 10.1ns ±15% 9.6ns ± 7% ~ (p=0.080 n=9+10) MapMid/11 9.88ns ±10% 9.44ns ±11% ~ (p=0.065 n=10+10) MapMid/12 9.90ns ±13% 10.04ns ± 9% ~ (p=1.000 n=10+8) MapMid/13 9.67ns ±14% 10.23ns ±10% ~ (p=0.209 n=10+9) MapMid/14 9.12ns ±14% 9.14ns ±13% ~ (p=0.927 n=10+10) MapMid/15 9.16ns ±12% 9.15ns ±16% ~ (p=0.955 n=10+10) MapMid/16 9.37ns ±11% 9.60ns ±23% ~ (p=0.825 n=9+10) MapLast/1 4.08ns ± 1% 3.92ns ± 0% -3.91% (p=0.000 n=10+9) MapLast/2 4.37ns ± 1% 4.28ns ± 1% -1.95% (p=0.000 n=10+10) MapLast/3 4.94ns ± 2% 4.65ns ± 1% -5.79% (p=0.000 n=9+8) MapLast/4 5.40ns ± 3% 5.02ns ± 2% -7.13% (p=0.000 n=9+9) MapLast/5 5.88ns ± 2% 5.67ns ± 2% -3.57% (p=0.000 n=10+10) MapLast/6 6.48ns ± 3% 5.90ns ± 2% -8.89% (p=0.000 n=10+10) MapLast/7 7.01ns ± 2% 6.27ns ± 5% -10.56% (p=0.000 n=10+10) MapLast/8 7.60ns ± 2% 6.62ns ± 2% -12.93% (p=0.000 n=9+10) MapLast/9 10.6ns ± 9% 10.9ns ±15% ~ (p=0.344 n=9+10) MapLast/10 11.0ns ±12% 10.9ns ±14% ~ (p=0.985 n=10+10) MapLast/11 11.4ns ±12% 11.8ns ±22% ~ (p=0.671 n=10+10) MapLast/12 11.6ns ±10% 12.1ns ±19% ~ (p=0.617 n=10+10) MapLast/13 12.5ns ±23% 11.8ns ±13% ~ (p=0.827 n=10+9) MapLast/14 10.5ns ±22% 10.4ns ± 5% ~ (p=0.797 n=10+9) MapLast/15 10.0ns ±15% 10.3ns ±16% ~ (p=0.565 n=10+10) MapLast/16 10.4ns ±12% 10.5ns ±13% ~ (p=0.889 n=10+9) MapCycle 22.3ns ± 1% 22.0ns ± 2% -1.43% (p=0.002 n=9+10) RepeatedLookupStrMapKey32 16.4ns ± 1% 16.6ns ± 1% +1.24% (p=0.000 n=10+9) RepeatedLookupStrMapKey1M 35.6µs ± 0% 35.4µs ± 1% -0.62% (p=0.002 n=10+10) NewEmptyMap 5.36ns ± 1% 9.05ns ± 1% +69.02% (p=0.000 n=10+8) NewSmallMap 51.2ns ± 2% 33.7ns ± 1% -34.22% (p=0.000 n=10+9) MapIter 83.8ns ± 1% 88.4ns ± 1% +5.55% (p=0.000 n=10+10) MapIterEmpty 4.32ns ± 3% 5.54ns ± 3% +28.12% (p=0.000 n=10+10) SameLengthMap 4.31ns ± 1% 4.59ns ± 2% +6.41% (p=0.000 n=9+10) BigKeyMap 24.2ns ± 2% 24.3ns ± 1% ~ (p=0.432 n=10+10) BigValMap 24.3ns ± 1% 24.4ns ± 2% ~ (p=0.200 n=10+9) SmallKeyMap 17.5ns ± 1% 18.5ns ± 2% +5.81% (p=0.000 n=9+10) MapPopulate/1 29.0ns ± 4% 18.8ns ± 1% -35.27% (p=0.000 n=10+9) MapPopulate/10 736ns ± 5% 693ns ± 4% -5.92% (p=0.000 n=10+10) MapPopulate/100 11.3µs ± 2% 10.8µs ± 3% -4.38% (p=0.000 n=10+10) MapPopulate/1000 139µs ± 8% 132µs ± 4% -5.10% (p=0.002 n=10+10) MapPopulate/10000 1.21ms ± 5% 1.16ms ± 5% -4.56% (p=0.002 n=10+10) MapPopulate/100000 12.2ms ± 3% 11.8ms ± 5% ~ (p=0.052 n=10+10) ComplexAlgMap 73.9ns ± 1% 74.4ns ± 2% ~ (p=0.161 n=9+10) GoMapClear/Reflexive/1 36.0ns ± 1% 26.9ns ± 2% -25.31% (p=0.000 n=10+10) GoMapClear/Reflexive/10 35.2ns ± 1% 24.4ns ± 1% -30.62% (p=0.000 n=10+10) GoMapClear/Reflexive/100 69.6ns ± 2% 59.2ns ± 1% -14.92% (p=0.000 n=10+10) GoMapClear/Reflexive/1000 1.06µs ± 2% 1.05µs ± 1% -1.16% (p=0.013 n=10+9) GoMapClear/Reflexive/10000 11.7µs ± 1% 11.7µs ± 1% ~ (p=0.542 n=10+10) GoMapClear/NonReflexive/1 96.3ns ± 1% 90.0ns ± 1% -6.52% (p=0.000 n=10+10) GoMapClear/NonReflexive/10 110ns ± 2% 101ns ± 0% -8.10% (p=0.000 n=10+7) GoMapClear/NonReflexive/100 270ns ± 2% 235ns ± 2% -12.94% (p=0.000 n=10+10) GoMapClear/NonReflexive/1000 3.02µs ± 2% 2.48µs ± 1% -17.92% (p=0.000 n=10+10) GoMapClear/NonReflexive/10000 23.7µs ± 1% 19.6µs ± 1% -17.30% (p=0.000 n=10+9) MapPop100 9.65µs ± 6% 9.18µs ± 8% -4.82% (p=0.008 n=9+10) MapPop1000 162µs ± 6% 148µs ± 4% -8.67% (p=0.000 n=9+9) MapPop10000 3.05ms ± 8% 2.82ms ±15% -7.66% (p=0.023 n=10+10) MapAssign/Int32/256 15.7ns ± 4% 14.6ns ± 2% -7.08% (p=0.000 n=10+10) MapAssign/Int32/65536 29.8ns ± 1% 30.4ns ± 0% +2.04% (p=0.000 n=10+8) MapAssign/Int64/256 14.9ns ± 5% 14.8ns ± 4% ~ (p=0.611 n=10+10) MapAssign/Int64/65536 30.3ns ± 2% 30.4ns ± 1% +0.54% (p=0.046 n=10+9) MapAssign/Str/256 17.8ns ± 3% 19.8ns ± 4% +11.08% (p=0.000 n=10+10) MapAssign/Str/65536 35.7ns ± 1% 36.4ns ± 1% +1.82% (p=0.000 n=10+10) MapOperatorAssign/Int32/256 18.8ns ± 5% 14.6ns ± 3% -22.57% (p=0.000 n=10+10) MapOperatorAssign/Int32/65536 29.8ns ± 1% 30.5ns ± 1% +2.39% (p=0.000 n=10+10) MapOperatorAssign/Int64/256 16.6ns ± 4% 15.0ns ± 6% -9.34% (p=0.000 n=10+10) MapOperatorAssign/Int64/65536 30.1ns ± 1% 31.7ns ± 2% +5.21% (p=0.000 n=10+10) MapOperatorAssign/Str/256 1.70µs ± 1% 1.61µs ± 2% -5.55% (p=0.000 n=10+8) MapOperatorAssign/Str/65536 289ns ± 7% 294ns ± 4% ~ (p=0.425 n=10+10) MapAppendAssign/Int32/256 34.3ns ± 2% 31.0ns ± 3% -9.59% (p=0.000 n=9+9) MapAppendAssign/Int32/65536 51.8ns ± 3% 47.1ns ±13% -9.17% (p=0.002 n=9+10) MapAppendAssign/Int64/256 32.5ns ± 8% 31.2ns ± 6% ~ (p=0.065 n=10+10) MapAppendAssign/Int64/65536 51.4ns ± 4% 47.2ns ±10% -8.07% (p=0.005 n=9+10) MapAppendAssign/Str/256 105ns ±12% 109ns ± 4% ~ (p=0.138 n=10+8) MapAppendAssign/Str/65536 101ns ±14% 81ns ± 8% -19.82% (p=0.000 n=10+9) MapDelete/Int32/100 32.0ns ± 1% 35.0ns ± 2% +9.59% (p=0.000 n=9+10) MapDelete/Int32/1000 27.0ns ± 3% 30.3ns ± 1% +12.10% (p=0.000 n=10+9) MapDelete/Int32/10000 29.2ns ± 1% 32.9ns ± 2% +12.80% (p=0.000 n=10+10) MapDelete/Int64/100 31.5ns ± 1% 35.7ns ± 2% +13.16% (p=0.000 n=10+10) MapDelete/Int64/1000 27.0ns ± 2% 30.6ns ± 1% +13.21% (p=0.000 n=10+10) MapDelete/Int64/10000 30.3ns ± 1% 34.4ns ± 3% +13.47% (p=0.000 n=10+10) MapDelete/Str/100 23.4ns ± 8% 26.7ns ± 6% +14.10% (p=0.000 n=10+9) MapDelete/Str/1000 31.0ns ± 2% 35.1ns ± 3% +13.19% (p=0.000 n=10+9) MapDelete/Str/10000 38.8ns ± 1% 43.4ns ± 2% +12.02% (p=0.000 n=9+10) Change-Id: I564ce0f40936589f0f9b837f7f2bbcca4c4a1070 Reviewed-on: https://go-review.googlesource.com/c/142437Reviewed-by:
Giovanni Bajo <rasky@develer.com> Reviewed-by:
Martin Möhrmann <martisch@uos.de> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Correct error introduced in CL 145417 on non-AIX systems. Fixes #28511 Change-Id: I6624939061425af19faccedd271f465d1fe6b975 Reviewed-on: https://go-review.googlesource.com/c/146277 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Agniva De Sarker authored
Effective Go and the FAQ still had some instances which showed the command line usage of godoc. Changed them to use go doc. Updates #25443 Change-Id: If550963322034e6848bc466f79e968e7220e4a88 Reviewed-on: https://go-review.googlesource.com/c/145222Reviewed-by:
-
Robert Griesemer authored
Also, renamed - noder.lineno -> noder.setlineno (because that's what it does) - noder.setlineno -> noder.pos (and return the src.XPos) Change-Id: I5d3442cf2af97028afcab028290152ce8d062927 Reviewed-on: https://go-review.googlesource.com/c/146317Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Tobias Klauser authored
Follow CL 146020 and enable RemoveAll based on Unlinkat and Openat on solaris. Updates #27029 Change-Id: I0b0e92f4422fa960a13dcd3e9adb57cd23f09ed4 Reviewed-on: https://go-review.googlesource.com/c/145839 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
-
Yury Smolsky authored
We have fixed the playground to display results of the program when it was timed out. This CL fixes how soon results will be displayed to the user. Change-Id: Ifb75828e0de12c726c8ca6e2d04947e01913dc73 Reviewed-on: https://go-review.googlesource.com/c/146237Reviewed-by:
-
Clément Chigot authored
AIX doesn't have HWCAP/HWCAP2 variables like Linux. Therefore, it relies on getsystemcfg syscall which can provide some information about the CPU. Change-Id: Ic0dc927e80890d4bf8f0bdfb43fad1e2b890d7a0 Reviewed-on: https://go-review.googlesource.com/c/144959 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Martin Möhrmann <moehrmann@google.com>
-
Ian Lance Taylor authored
RELNOTES=yes Change-Id: Ie7090b5a6edd548a49bdc4295e01cb686dfe6522 Reviewed-on: https://go-review.googlesource.com/c/146023 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Darien Raymond authored
I am working on a TLS server program, which issues new TLS certificates on demand. The new certificates will be added into tls.Config.Certificates. BuildNameToCertificate will be called to refresh the name table afterwards. This change will reduce some workload on existing certificates. Note that you can’t modify the Certificates field (or call BuildNameToCertificate) on a Config in use by a Server. You can however modify an unused Config that gets cloned in GetConfigForClient with appropriate locking. Change-Id: I7bdb7d23fc5d68df83c73f3bfa3ba9181d38fbde GitHub-Last-Rev: c3788f4116be47f2fdb777935c421e7dd694f5c8 GitHub-Pull-Request: golang/go#24920 Reviewed-on: https://go-review.googlesource.com/c/107627Reviewed-by:
Filippo Valsorda <filippo@golang.org>
-
Oliver Stenbom authored
On unix systems, long enough path names will fail when performing syscalls like `Lstat`. The current RemoveAll uses several of these syscalls, and so will fail for long paths. This can be risky, as it can let users "hide" files from the system or otherwise make long enough paths for programs to fail. By using `Unlinkat` and `Openat` syscalls instead, RemoveAll is safer on unix systems. Initially implemented for linux, darwin, dragonfly, netbsd and openbsd. Not yet implemented on freebsd due to fstatat 64-bit inode compatibility issues. Fixes #27029 Co-authored-by:
Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by:
Julia Nedialkova <yulia.nedyalkova@sap.com> Change-Id: I978a6a4986878fe076d3c7af86e7927675624a96 GitHub-Last-Rev: 9235489c81b90c228210144b7c25b28a46bb80b7 GitHub-Pull-Request: golang/go#28494 Reviewed-on: https://go-review.googlesource.com/c/146020 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Clément Chigot authored
This commit adds a new file format in cmd/internal/objfile for XCOFF. It also adapts tests inside cmd/nm for AIX. Updates: #25893 Change-Id: I1e55ea0b7f7d08a871343bee27d11e2d3baad254 Reviewed-on: https://go-review.googlesource.com/c/145397 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
Windows implementation of Symlink uses CreateSymbolicLink Windows API. The API requires to identify the target type: file or directory. Current Symlink implementation uses Lstat to determine symlink type, but Lstat will not be able to determine correct result if destination is symlink. Replace Lstat call with Stat. Fixes #28432 Change-Id: Ibee6d8ac21e2246bf8d0a019c4c66d38b09887d4 Reviewed-on: https://go-review.googlesource.com/c/145217 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Change-Id: I5c7ec9676b5573c883c196459acea85aa9ff8130 Reviewed-on: https://go-review.googlesource.com/c/146021 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
