Optimization Levels

The levels are presets, and the names understate how discrete they are. -O0 is not "a bit slower" — it is a fundamentally different compilation strategy, where every variable lives in memory, every statement boundary is preserved, and nothing moves. That is why it builds fast and debugs perfectly, and why it can be several times slower at run time than -O1.

The step from -O0 to -O1 is the largest one in every direction: most of the runtime gain, most of the debugging loss, and a moderate increase in compile time. -O2 adds the expensive interprocedural and loop work and is the default that mainstream distributions build with. -O3 adds transformations that trade code size for speed — more aggressive inlining and unrolling, and vectorization that -O2 in GCC historically declined — and is where the "higher is faster" intuition starts to fail.

-Os optimizes for size while keeping most speed optimizations that do not grow code; -Oz (Clang, and GCC since 12) goes further and accepts real slowdowns to shrink further. -Og is the newer and genuinely useful one: optimize, but only in ways that keep the debugging experience intact, which is the level to build with when you need to attach a debugger to something that also has to run at a realistic speed.

The transformations that -O3 adds beyond -O2 mostly buy speed by spending code size: inline more call sites, unroll more loop bodies, version more loops so a vectorized variant and a scalar fallback both exist. Each of those removes work per iteration and adds instructions to the binary — and instructions are a scarce resource for a reason that has nothing to do with the compiler.

A modern core has an instruction cache measured in tens of kilobytes. Code that does not fit is fetched from further away, and an instruction fetch that misses costs the same order of magnitude as a data miss while being much harder to see in a profile. Aggressive inlining across a call-heavy codebase can push a hot working set out of that cache, at which point the program executes fewer instructions per iteration and takes longer per iteration. The instruction cache is Computer Architecture's subject and is linked below; note that the limit is a property of the machine, not of the compiler.

There are quieter reasons too. Unrolling increases live values and can push register allocation into spilling, converting register accesses into memory accesses in the hottest loop in the program — [[spilling]]. Loop versioning doubles the branch footprint and can degrade branch predictor behavior. More inlining means larger functions, which means less precise analysis in some passes with per-function limits, so an aggressive setting occasionally *loses* an optimization it would have found at -O2. And more optimization means longer compile times, which for a large project is a real cost paid on every build.

None of this makes -O3 a bad choice. It makes it an empirical one. The measurements that exist consistently show that the difference between -O2 and -O3 is small in either direction for most programs and occasionally large in one direction for a specific one — and which direction is a property of the program, its working set, and the machine it runs on. The honest procedure is to build both and measure the workload you actually care about, which is measure-before-optimizing applied to the compiler itself.

The default answer for most projects is -O2, and the reason is not that it is fastest — it is that it is the setting every distribution, every CI system and every compiler vendor tests most heavily, so it has the fewest surprises. Deviating from it is a decision that should be backed by a measurement of your workload.

For a size-constrained target — embedded firmware, a WebAssembly module served over a network, a container image where the binary is the payload — -Os or -Oz is chosen for the axis that actually matters, and the speed cost is accepted deliberately. For a service where debuggability under load is a first-class concern, -Og with full debug info is a defensible production setting.

Two flags matter more than the level for many programs, and both are orthogonal to it. -march=native (or a specific -march) tells the compiler which instruction set extensions it may use, and can matter far more than any -O step for vectorizable code — at the cost of a binary that will not run on older machines. -flto enables link-time optimization, which lets inlining and interprocedural analysis cross translation-unit boundaries and is frequently worth more than the -O2-to--O3 step, at the cost of link time and memory — [[link-time-optimization]].

And the flag that beats all of them for the right workload is -fprofile-use: profile-guided optimization replaces the cost model's guesses with measurements of your program, so the inlining and layout decisions are made about the paths that are actually hot. It costs a two-stage build and an instrumented run on a representative workload, and "representative" is doing a lot of work in that sentence — [[profile-guided-optimization]] and [[pgo-tradeoffs]].