What does the Go compiler do differently at a call site that a PGO profile marks hot?

## The idea: spend the optimisation budget where the time is Without a profile the compiler has to decide, from the source alone, which calls are worth inlining and which indirect calls might be worth specialising. It cannot tell a function called once at startup from one called ten thousand times a second, so it applies uniform, fairly conservative rules — inlining aggressively everywhere would bloat the binary and hurt instruction cache behaviour for no gain. A PGO profile removes the guesswork for the small fraction of call sites that actually matter. ## Effect one: hot call-site inlining When the profile shows that a particular call site accounts for meaningful CPU time, the compiler is willing to inline the callee there even if it would normally reject it as too large. This is per call site, not per function: the same function can be inlined at the hot caller and left as a real call everywhere else, so the binary does not grow across the board. Inlining matters for more than the saved call instruction. Once the callee's body is in the caller, the compiler can propagate constants into it, fold branches that are provably not taken for that caller, and — importantly in Go — run escape analysis over the combined body, so a value that had to be heap-allocated because it was passed to an opaque call can sometimes stay on the stack. This is why PGO often reduces allocations as a side effect, not just cycles. ## Effect two: devirtualization of hot indirect calls Go code reaches for interfaces constantly, and a call through an interface is an indirect call: the target is loaded from the interface value's method table at run time, so the compiler cannot inline it and the CPU cannot predict it as well as a direct call. If the profile shows a hot interface call site whose receiver is overwhelmingly one concrete type, PGO turns it into a conditional direct call. Conceptually the compiler rewrites ```go row, err := s.Product(ctx, id) // indirect: s is an interface ``` into "if the dynamic type of `s` is `*pgStore`, call `(*pgStore).Product` directly; otherwise do the original indirect call". The guarded direct call preserves semantics exactly — a different implementation still works, it just takes the slow path — while the fast path becomes an ordinary static call that can then be inlined by the pass above. The two optimisations compound: devirtualization is often valuable mainly because it unlocks inlining at a site that could never be inlined before. ## What is left alone Cold code compiles exactly as it did without the profile. This is a deliberate property: PGO is meant to be safe to leave on, so it must not make the ninety-nine percent of the program that is not hot bigger or slower. It also does not change semantics — a `-pgo=off` and a `-pgo=auto` build of the same source are behaviourally identical, which is what makes an A/B comparison of the two binaries a valid experiment. ## Scope of the effect The profile applies to the entire build, not just to your own packages. Dependencies and the standard library are recompiled under the profile's influence too, which is why a hot path that spends its time inside a standard-library function can benefit. The flip side is build cost: because code generation for essentially every package now depends on the profile's content, adding or changing `default.pgo` invalidates cached package builds and triggers a wide rebuild. Later Go releases reduced that overhead considerably, but it remains the reason the first profile-guided CI run feels slow. ## How much to expect The Go project reports typical CPU improvements in the low single digits — commonly quoted as roughly 2 to 7 percent for a representative profile, with more on some workloads. That is a meaningful win for a service where you cannot change the code, and a poor trade if you were hoping for a multiple. The honest framing in an interview is that PGO is the cheapest few percent available — no source change, one file, one flag that is already the default — and that anything larger has to come from changing what the program does, not from how it is compiled. ## The mental model to carry A profile does not tell the compiler anything new about semantics; it tells it about *distribution*. Every optimisation PGO enables is one the compiler already knew how to perform but could not justify performing everywhere. That is why the quality of the profile decides the quality of the result: point it at the wrong workload and the compiler will faithfully optimise the wrong call sites.