在大多数项目中,我没有看到任何
-Ox
标志,您认为这是每个项目的标准,因为它可以极大地提高程序的速度。
是否有任何特定原因不使用
-Ox
或其非 gcc 对应项进行编译?
调试未优化的程序要容易得多,因为目标代码往往是源代码的更直接翻译。 启用优化后,编译器可能会重新排序语句或通过将多个操作合并为一个操作来完全消除它们。这意味着在调试程序(或核心转储)时,不存在从程序映像中的位置到源代码行的直接映射。
GCC 4.8添加了一个新的优化级别,这是性能和可调试性之间的一个很大的折衷:
引入了新的常规优化级别
。它满足了快速编译和卓越调试体验的需求,同时提供合理水平的运行时性能。整体开发体验应该比默认的优化级别更好-Og
。-O0
使用
-Og
,编译器会进行简单的优化,不会使调试变得更加困难,并且编译时间不会太长,因此代码的性能比完全未优化的代码更好,但仍然可以调试。
原因之一是您想使用调试器单步执行代码。如果启用优化,则可以重新排序或错过语句,并且程序的执行将不必逐步遵循源代码中的内容。变量的值可能不可用,因为它们已被优化掉。因此,当您在调试器中运行程序时,很难推断出程序正在做什么。
避免优化的另一个原因是您在程序中使用了未定义的行为,优化可能会导致您的程序崩溃。 (事实上,这就是使用优化的原因 - 寻找此类错误。)
这使得 Debug 更加准确,无需优化。
未使用的变量、冗余语句不会被跳过。
在一个比较旧的项目中,我们所有的测试都是通过调试构建完成的,包括很多打印语句。对于交付给客户的最终版本,决定不使用测试较少的零售版本(使用 gcc 的完整优化选项),因为这可能会引入与时间相关的问题(实际上,由于特定的原因,现在发现的缺陷被掩盖了)调试构建的时间),而且客户对当前的操作速度感到非常满意。
在我当前的项目中,很多代码要放置在 ROM 中(最初:全部),然后我们显然不想删除死代码,因为将来的更新 - 放置在 ram 中 - 仍然可以使用ROM 代码,减少 RAM 空间需求。
另外,默认值是什么?优化空间还是执行时间?不选择是唯一正确的选择。