PGO or not PGO this is the dilemma. Step 2

This explains how Profile-Guided Optimization (PGO) works in practice for large C/C++ binaries like mysqld and why its benefits come from reshaping machine code rather than tuning for specific input values. PGO is a two-pass build: first compile with instrumentation (e.g., -fprofile-generate) so the compiler injects counters on every control-flow edge (branches, loop back-edges, call sites), run a training workload to emit profile data, then recompile using those counts. The compiler uses per-edge counts to drive targeted transformations: aggressive inlining of hot call sites, laying out branches so hot paths fall through and cold paths are moved to .text.unlikely, hot/cold function splitting, whole-binary function reordering (especially effective with LTO), indirect-call promotion to guarded direct calls, register-allocation and unrolling trade-offs favoring hot code, and switch-to-jump-table decisions. These changes improve instruction-cache and iTLB locality and reduce pipeline stalls by aligning the executable’s physical layout with real control-flow hot spots.

The central claim is that PGO optimizes the shape of control flow, not the runtime data values, so a training workload only needs to exercise the same hot paths as production to deliver wins. Broad test suites that touch many code paths (e.g., MTR) transfer well because they reveal the binary’s hot/cold structure; narrow synthetic workloads (e.g., a limited sysbench trace) can mislead the optimizer and produce slower builds. For large, order-sensitive binaries, whole-binary reordering driven by accurate per-edge profiles is often the single biggest source of performance improvement.