• Measuring performance is hard. Unfortunately it's easy to benchmark the wrong things, or benchmark tiny parts of their program rather than everything. That's the danger with using individual benchmarks which don't measure the time taken to perform a real-world action. Some really useful tools I've found for this are:

    • Benchmarking, as in this article - most useful for comparing the impact of a change on an isolated bit of code.

    • Measure the absolute impact, not % increases, e.g. a 100% increase from 0.0001ms 0.0002ms in response times to is unlikely to be important.

    • Profiling - check the call graph to find out which functions are called most often and take longest, particularly in hot paths, then work on those.

    • Flame Graphs - these make profiling tools easier to interpret: https://golangnews.com/stories/675

    • Real world use-cases - make sure your benchmarking covers real-world use, try to make them measure a whole request cycle for example, use real data.

    • Instrumenting request cycles - so add timings to important parts of your request cycle (for a web app).

    Here's a collection of stories on profiling