diff options
| author | Josh Bleecher Snyder <josharian@gmail.com> | 2017-05-10 10:19:43 -0700 |
|---|---|---|
| committer | Josh Bleecher Snyder <josharian@gmail.com> | 2017-06-14 05:28:24 +0000 |
| commit | aafd96408feef0785d32fd3e1c5a67d4159a98e7 (patch) | |
| tree | 38bc0efb8c9769aceeab83d7dfd1b67bd58740e0 /src/syscall/exec_linux.go | |
| parent | 2f7fbf8851e4c45f7e0d207836a3c7a97eaa1823 (diff) | |
| download | go-aafd96408feef0785d32fd3e1c5a67d4159a98e7.tar.xz | |
runtime: speed up stack copying
I was surprised to see readvarint show up in a cpu profile.
Use a few simple optimizations to speed up stack copying:
* Avoid making a copy of the cache.entries array or any of its elements.
* Use a shift instead of a signed division in stackmapdata.
* Change readvarint to return the number of bytes consumed
rather than an updated slice.
* Make some minor optimizations to readvarint to help the compiler.
* Avoid called readvarint when the value fits in a single byte.
The first and last optimizations are the most significant,
although they all contribute a little.
Add a benchmark for stack copying that includes lots of different
functions in a recursive loop, to bust the cache.
This might speed up other runtime operations as well;
I only benchmarked stack copying.
name old time/op new time/op delta
StackCopy-8 96.4ms ± 2% 82.7ms ± 1% -14.24% (p=0.000 n=20+19)
StackCopyNoCache-8 167ms ± 1% 131ms ± 1% -21.58% (p=0.000 n=20+20)
Change-Id: I13d5c455c65073c73b656acad86cf8e8e3c9807b
Reviewed-on: https://go-review.googlesource.com/43150
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Diffstat (limited to 'src/syscall/exec_linux.go')
0 files changed, 0 insertions, 0 deletions
