<p>i stumbled upon some interesting differences between go 1.6 and 1.7 which i wanted to share and maybe get some input/explanation: <a href="https://gist.github.com/anonymous/945c67499a233b0bd47e5631baf68de5">https://gist.github.com/anonymous/945c67499a233b0bd47e5631baf68de5</a></p>
<p>it seems that with 1.6 it was worth to "cache" access to deeper-nested structures, which is not necessary in 1.7 anymore?</p>
<hr/>**评论：**<br/><br/>tv64738: <pre><pre><code>bodies := [1000]Body{}
...
for _, bb := range bodies {
bb.Position[0] += bb.Velocity[0]
</code></pre>
<p>That <code>bb</code> there is a copy of an array element, mutating it is a bit pointless.</p></pre>bl4blub: <pre><p>ah yes, good point - thank you!</p></pre>boarhog: <pre><blockquote>
<p>a very simple benchmark that shows difference between go 1.6 and 1.7</p>
</blockquote>
<p><em>Prints version number</em> <sup><sup><sup><sup><sup>/s</sup></sup></sup></sup></sup></p></pre>funny_falcon: <pre><p>Looks like you should fill an issue for <code>forin</code> case. It is clear degradation.</p>
<p>On other hand, <code>forin</code> is absolutely meaningless, cause it does not change content of <code>bodies</code> .</p>
<p>Still, response from go-authors is desirable.</p></pre>Faffenheim: <pre><blockquote>
<p>Looks like you should fill an issue for forin case</p>
</blockquote>
<p>It's known. See
<a href="https://github.com/golang/go/issues/15925" rel="nofollow">https://github.com/golang/go/issues/15925</a></p></pre>jere_jones: <pre><p>Maybe it is so much slower because it has to allocate new objects since the copies are being mutated. I bet running the tests with memory profiling on would be very educational.</p></pre>funny_falcon: <pre><p>No. Structure on stack is mutable. And it is same variable in all iterations (cause of language specification). No need to allocate anything on heap. It is clear regression despite test is meaningless.</p></pre>bl4blub: <pre><p>do you mean <code>--benchmem</code>? its <code>0 B/op</code> and <code>0 allocs/op</code></p></pre>boarhog: <pre><blockquote>
<p>degradation</p>
</blockquote>
<p>I think regression is a more common term</p></pre>TheMerovius: <pre><p>I wouldn't be surprised. Better <a href="https://en.wikipedia.org/wiki/Common_subexpression_elimination" rel="nofollow">CSE</a> is, AFAIK, one of the major benefits of SSA. You can always try to <a href="https://en.wikipedia.org/wiki/Common_subexpression_elimination" rel="nofollow">look</a> at the specific things the SSA backend is doing, but of course this doesn't give you any insights into what's happening for go 1.6.</p>
<p>Honestly, I'm surprised that there really is any benefit. I wouldn't be surprised if this turns out to be such a subtle microbenchmark, that it depends on code alignment or so.</p></pre>
