[diamondlovesyou]

The power of the optimizations available to C++ are what make it so fast (see how slow debug mode is vs -O2/etc), and what allow C++ to be fast in the face of common/easy-to-understand, but technically perf-hostile, patterns. Bit counting loops vs popcnt, auto-vectorization, DCE, RCE, CSE, CFG simplification, LTCG/LTO, and so on. These things let you write "high level" (to a point - there are some ways to do "high level" paradigms and absolutely eviscerate the compilers ability to optimize) code/algos and still get great hardware level performance. This is so much more important overall than the time it takes to compile your program, and even more so once you consider that often such programs are shipped once and then enter maintenance mode.

It doesn't really have anything to do with compatibility (not entirely, but the things that are the biggest issue to good optimization quality and are fixable are things that need a system-level rethinking on how hardware exceptions happen). It just isn't reasonable to expect developers to know how to optimize, and it doesn't scale.

[cvoss]

In many contexts, one should rarely pass -O2/-O3. A project that is built thousands of times during development may only be run on intensive workloads (where -O2 performance is actually a necessity) a handful of times by comparison. A dev build can usually be -O0, which can dramatically improve compilation time.

[htfy96]

It depends. O0 turns off a few trimming optimizations and could potentially causes more information (code or DWARF) to be included in the objects, which may eventually slow down the compilation. In our large code base, we found that -O1 works best in terms of compilation speed.

[ahartmetz]

Yeah, -O1 is usually a good choice. I get the occasional <value optimized out> while debugging, well I add another logging statement and rerun.

[rerdavies]

There doesn't seem to be a significant difference between -O0 and -O2/-O3 compile times.