optimization - 是否有任何理由不进行优化进行编译？

Question

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

是否有任何特定原因不使用-Ox或非 gcc 对应物进行编译？

Answer 1

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

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

引入了一个新的通用优化级别 , -Og。它满足了对快速编译和卓越调试体验的需求，同时提供了合理水平的运行时性能。开发的整体体验应该优于默认的优化级别-O0。

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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