Efficient Go

Chapter 9. Data-Driven Bottleneck Analysis

Programmers are usually notoriously bad at guessing which parts of the code are the primary consumers of the resources. It is all too common for a programmer to modify a piece of code expecting see a huge time savings and then to find that it makes no difference at all because the code was rarely executed.

Jon Louis Bentley, Writing Efficient Programs

One of the key steps to improving the efficiency of our Go programs is to know where is the main source of the latency or resource usage you want to improve. Therefore, we should make a conscious effort to first focus on the code parts that contribute the most (the bottleneck or hot spot) to get the biggest value for our optimizations.

It is very tempting to use our experience in software development to estimate what part of the code is the most expensive or too slow to compute. We might have already seen similar code fragments causing efficiency problems in the past. For example, “Oh, I worked with linked lists in Go, it was so slow, this must be it!” or “We create a lot of new slices here, I think this is our bottleneck, let’s reuse some.” We might still remember the pain or stress it might have caused. Unfortunately, those feelings-based conclusions are often wrong. Every program, use case, and environment is different. The software might struggle in other places. It’s essential to uncover that part quickly and reliably so we know where to spend our optimization efforts.

Fortunately, ...