Go 1.8 vs go 1.7 performance improvements

<p>Preliminary <a href="https://golang.org/test/bench/go1/">Go1 benchmark</a> results comparing go tip to go1.7 suggest that go1.8 will be faster:</p> <pre><code>name old time/op new time/op delta BinaryTree17-4 2.88s ± 3% 2.81s ± 2% -2.41% (p=0.001 n=9+9) Fannkuch11-4 3.10s ± 1% 3.03s ± 2% -2.50% (p=0.000 n=9+10) FmtFprintfEmpty-4 54.7ns ± 7% 49.5ns ± 6% -9.48% (p=0.000 n=10+10) FmtFprintfString-4 152ns ± 6% 140ns ±10% -7.69% (p=0.006 n=10+10) FmtFprintfInt-4 142ns ± 8% 120ns ± 5% -15.33% (p=0.000 n=10+10) FmtFprintfIntInt-4 218ns ± 9% 182ns ± 7% -16.45% (p=0.000 n=10+10) FmtFprintfPrefixedInt-4 210ns ± 8% 189ns ± 7% -9.78% (p=0.000 n=10+9) FmtFprintfFloat-4 308ns ±11% 285ns ± 8% -7.69% (p=0.003 n=10+10) FmtManyArgs-4 877ns ± 5% 809ns ± 1% -7.74% (p=0.000 n=9+9) GobDecode-4 8.13ms ± 4% 7.23ms ± 3% -11.03% (p=0.000 n=10+10) GobEncode-4 6.66ms ± 1% 6.57ms ±10% ~ (p=0.515 n=8+10) Gzip-4 248ms ± 0% 249ms ± 1% ~ (p=1.000 n=7+8) Gunzip-4 38.4ms ± 6% 38.8ms ±10% ~ (p=0.739 n=10+10) HTTPClientServer-4 57.5µs ± 7% 62.6µs ± 7% +8.93% (p=0.000 n=9+10) JSONEncode-4 18.8ms ± 4% 18.8ms ± 4% ~ (p=0.780 n=9+10) JSONDecode-4 53.0ms ± 4% 54.7ms ± 9% ~ (p=0.218 n=10+10) Mandelbrot200-4 4.85ms ± 1% 4.79ms ± 1% -1.20% (p=0.002 n=10+10) GoParse-4 3.61ms ± 5% 3.47ms ± 2% -3.76% (p=0.000 n=10+8) RegexpMatchEasy0_32-4 86.6ns ± 4% 86.4ns ± 5% ~ (p=0.765 n=10+9) RegexpMatchEasy0_1K-4 206ns ± 5% 859ns ± 3% +317.14% (p=0.000 n=10+10) RegexpMatchEasy1_32-4 87.5ns ± 4% 80.3ns ± 3% -8.25% (p=0.000 n=10+10) RegexpMatchEasy1_1K-4 389ns ± 6% 359ns ± 2% -7.59% (p=0.000 n=10+10) RegexpMatchMedium_32-4 137ns ± 4% 126ns ± 3% -7.97% (p=0.000 n=9+9) RegexpMatchMedium_1K-4 41.8µs ± 3% 39.6µs ± 5% -5.24% (p=0.000 n=8+10) RegexpMatchHard_32-4 1.93µs ± 0% 1.96µs ± 2% +1.37% (p=0.011 n=9+10) RegexpMatchHard_1K-4 59.6µs ± 7% 59.5µs ± 5% ~ (p=0.497 n=10+9) Revcomp-4 520ms ± 7% 461ms ± 5% -11.36% (p=0.000 n=9+9) Template-4 62.7ms ± 3% 55.4ms ± 1% -11.58% (p=0.000 n=9+10) TimeParse-4 338ns ±11% 308ns ± 2% -8.74% (p=0.000 n=10+9) TimeFormat-4 350ns ± 0% 324ns ± 1% -7.40% (p=0.000 n=10+10) </code></pre> <p>As for <code>RegexpMatchEasy0_1K</code> performance degradation, it <a href="https://github.com/golang/go/issues/17456">should be fixed</a> before go1.8 is out.</p> <hr/>**评论：**<br/><br/>devsquid: <pre><p>It would be interesting to see 1.8 version all other versions of Go</p></pre>mixedCase_: <pre><p>Holy mama every release manages to amaze me. Keep up the great work!</p></pre>kodemizer: <pre><p>That RegexpMatchEasy0_1K result is worrying. </p></pre>UniverseCity: <pre><p>OP mentioned they&#39;re working on it at the bottom. <a href="https://github.com/golang/go/issues/17456">Link for the lazy</a>.</p></pre>kodemizer: <pre><p>Thanks. </p> <p>For the extra lazy: </p> <blockquote> <p>Looks like this is related to the change in how bytes.Index works. @TocarIP</p> <p>When looking for a smallish multicharacter string (in this case, 26 characters), we used to look for the first character, then check the remaining characters, then repeat. Now we use fun SSE (AVX?) instructions to look for multiple characters at once. The new way will definitely be faster when the first character matches but the rest don&#39;t (it is not slowed down by partial matches). The old way looks like it is faster when there are few matches of the first character. I&#39;m surprised about how much faster it is, however.</p> <p>It is possible that we should do some combination algorithm, looking for just the first character and switching once we get a few false positives (partial but not complete matches).</p> <p>All that said, the regexp is still doing &gt;1GB/sec. I think this may be an instance of &#34;something blazingly fast got a bit less blazingly fast&#34;.</p> </blockquote></pre>Yojihito: <pre><blockquote> <p>For the extra lazy:</p> </blockquote> <p>Guilty.</p></pre>nosmileface: <pre><p>In my pnoise benchmark I saw a nice boost with Go 1.7.1, would be interesting to see if Go 1.8 improves it further: <a href="https://github.com/nsf/pnoise/commit/1dd95cf7692841c91067818a37e92370f3caeedf" rel="nofollow">https://github.com/nsf/pnoise/commit/1dd95cf7692841c91067818a37e92370f3caeedf</a>. But I&#39;ll wait for the release.</p></pre>mcandre: <pre><p>dont give a shit about performance, just make <code>go</code> follow symlinks correctly when discovering vendor/, and stop asking for bullshit GOPATH customization; just shove that shit in ~/go every time</p> <p>Go&#39;s package system is so screwed, everyone and their dog has a third party Go package manager alternative</p> <p>NPM works, RubyGems works, hell even CPAN works. WTF google</p></pre>Sphax: <pre><p>Nice rant</p></pre>diosio: <pre><p>Gopath can suck it.</p></pre>