I think the poor optimisation performance described in this post is really a deliberate tradeoff made by the go compiler team. Rather than producing highly-optimised code for the best performance in some cases (which is often a fool's errand anyway), the compiler produces good enough code; quickly, and its architecture is not overly complicated by advanced optimisation procedures.
In my experience, go's high compilation speed compared to C++ is a great help to development, and I would gladly give away complicated optimisations for this enhancement. For high-throughput programs, time spent on manual optimisation or architectural work has a much higher payout than the marginal improvements of optimising compilers, when considering the continuous cost of slow compilation.
1 comment
[ 2.9 ms ] story [ 10.0 ms ] threadIn my experience, go's high compilation speed compared to C++ is a great help to development, and I would gladly give away complicated optimisations for this enhancement. For high-throughput programs, time spent on manual optimisation or architectural work has a much higher payout than the marginal improvements of optimising compilers, when considering the continuous cost of slow compilation.