e27*_*314 36 c++ debugging optimization gcc
我正在使用-O3编译程序以获得性能,使用-g编译调试符号(如果发生崩溃,我可以使用核心转储).有一件事困扰我,-g选项会导致性能下降吗？当我查看使用和不使用-g的编译输出时,我看到没有-g的输出比使用-g的编译输出小80%.如果额外的空间用于调试符号,我不关心它(我猜)因为在运行时没有使用这部分.但是如果没有-g的编译输出中的每条指令,我需要在编译输出中用-g做更多4条指令,我当然更愿意停止使用-g选项,即使代价是无法处理核心转储.
如何知道程序内部调试符号部分的大小,一般情况下使用-g进行编译会创建一个比没有-g编译的相同代码运行得慢的程序？
Mar*_* A. 52
引用gcc文档
GCC允许您使用-g和-O.优化代码所采用的快捷方式有时会产生令人惊讶的结果:您声明的某些变量可能根本不存在; 控制流可能会短暂地移动到你没想到的地方; 某些语句可能无法执行,因为它们计算的结果不变或者它们的值已经存在; 一些语句可能在不同的地方执行,因为它们已被移出循环.
这意味着:
我将为您插入调试符号,但如果优化通过将其删除,我将不会尝试保留它们,您将不得不处理
调试符号不会写入代码,而是写入另一个称为"调试部分"的部分,该部分甚至不在运行时加载(仅由调试器加载).这意味着:没有代码更改.您不应该注意到代码执行速度的任何性能差异,但如果加载器需要处理更大的二进制文件或者如果它以某种方式考虑增加的二进制大小,您可能会遇到一些缓慢.您可能需要自己对应用程序进行基准测试,以便在特定情况下100%确定.
请注意,gcc 4.8 还有另一个选项:
-Og优化调试体验.
-Og启用不会干扰调试的优化.它应该是标准编辑 - 编译 - 调试周期的优化级别,提供合理的优化级别,同时保持快速编译和良好的调试体验.
此标志将影响性能,因为它将禁用任何会干扰调试信息的优化传递.
最后,甚至可能会发生某些优化更适合特定体系结构而不是另一个体系结构,除非指示为您的特定处理器执行此操作(请参阅架构的march/mtune选项),在O3中gcc将尽力做到最好通用架构.这意味着在某些人为的场景中,你甚至可能会遇到O3比O2慢的情况."尽力而为"并不总是意味着"最好的".
| 归档时间： |
|
| 查看次数： |
9135 次 |
| 最近记录： |