有没有理由在没有优化的情况下进行编译？

Question

在大多数项目中，我没有看到任何-Ox标志，您认为这些标志是每个项目的标准，因为它可以大大提高程序的速度。

是否有任何具体原因无法使用-Ox或非gcc对应方编译？

Answer 1

一个原因是，如果您想使用调试器逐步执行代码。如果启用了优化，则可以重新排序或错过语句，并且程序的执行不必一步一步地遵循源代码中的内容。变量值可能无法使用，因为它们已经过优化。因此，在调试器中运行程序时，很难推断程序正在做什么。

避免优化的另一个原因是您在程序中使用了未定义的行为，优化可能会导致程序中断。 （事实上​​，这是使用优化的原因 - 找到这样的错误。）

Answer 2

调试未经优化的程序要容易得多，因为目标代码往往是源代码的更直接的翻译。启用优化后，编译器可能会通过将多个操作合并为一个来重新排序语句或完全消除它们。这意味着在调试程序（或核心转储）时，没有从程序映像中的位置到源代码行的直接映射。

GCC 4.8添加了一个新的优化级别，这是性能和可调试性之间的一个很好的折衷方案：

  

引入了新的常规优化级别-Og。它满足了快速编译和卓越调试体验的需求，同时提供了合理的运行时性能。开发的总体体验应优于默认优化级别-O0。

使用-Og编译器执行简单的优化，这些优化不会使调试变得更加困难并且编译时间不会太长，因此代码的性能优于完全未优化的代码，但仍可以进行调试。

Answer 3

这使得Debug无需优化即可更准确。

未使用的变量，不会跳过冗余语句。

Answer 4

在一个较旧的项目中，我们所有的测试都是使用调试版本完成的，包括很多打印语句。对于交付给客户的最终构建，决定不使用经过较少测试的零售构建（使用gcc的完整优化选项），因为这可能会引入与时间相关的问题（实际上，由于具体问题，现在掩盖了缺陷的发现调试的时间安排），并且因为客户对当前的操作速度感到满意。

在我当前的项目中，很多代码都放在ROM中（最初是：all），然后我们显然不希望删除死代码，因为将来的更新 - 放在ram中 - 然后仍然可以利用rom代码，减少ram中的空间需求。

另外，默认是什么？优化空间或执行时间？不选择是唯一正确的选择。