Optimization 有没有理由不进行优化就编译？

在大多数项目中，我看不到任何

-Ox

标志，您认为这是每个项目的标准标志，因为它可以显著提高程序的速度

---

不使用

-Ox

编译有什么具体原因吗？或者它是非gcc对应项吗？

这使得调试更准确，无需优化

---

未使用的变量、冗余语句将不会被跳过。

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

---

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

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

添加了一个新的优化级别，这是性能和可调试性之间的一个重大折衷：

引入了一个新的通用优化级别，

-Og

。它满足了快速编译和卓越调试体验的需要，同时提供了合理水平的运行时性能。总体开发经验应优于默认的优化级别

-O0

---

使用

-Og

编译器可以进行简单的优化，不会增加调试难度，也不会花费太长时间进行编译，因此代码的性能比完全未优化的代码要好，但仍然可以进行调试。

在一个稍旧的项目中，我们所有的测试都是通过调试构建完成的，包括许多打印语句。对于交付给客户的最终构建，决定不使用测试较少的零售构建（使用gcc的完整优化选项），因为这可能会带来与时间相关的问题（实际上，由于调试构建的特定时间，缺陷的发现现在被掩盖了），因为客户对目前的运营速度非常满意

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

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