I think there are two schools of thought:<p>1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don&#x27;t matter as long as we come below the benchmark at ship time.<p>2) Perf improvements should be &quot;locked in&quot; and not regressed, unless strenuously justified.<p>I think the parent is of group (2), where it doesn&#x27;t necessarily matter that it&#x27;s better than the benchmark of &quot;against other compilers&quot; but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification.<p>I think both groups have valid points. I think (2) is especially good at preventing &quot;perf creep&quot; wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone&#x27;s just slow, but they have no impetus to improve because they&#x27;re still better than the competition.