用-g gcc标志编译的程序是否比没有-g编译的同一程序慢?

时间:2014-06-09 09:12:07

标签: c++ debugging gcc optimization

我用-O3编译程序以获得性能,使用-g编译调试符号(如果崩溃我可以使用核心转储)。有一件事困扰我,-g选项会导致性能下降吗?当我查看使用和不使用-g的编译输出时,我看到没有-g的输出比使用-g的编译输出小80%。如果额外的空间用于调试符号,我不关心它(我猜)因为在运行时没有使用这部分。但是如果没有-g的编译输出中的每条指令,我需要在编译输出中用-g做更多的4条指令,我当然更愿意停止使用-g选项,即使代价是无法处理核心转储。 / p>

如何知道程序内部调试符号部分的大小,一般情况下使用-g进行编译会创建一个比没有-g编译的相同代码运行得慢的程序吗?

1 个答案:

答案 0 :(得分:49)

引用gcc documentation

  

GCC允许您将-g与-O一起使用。通过优化采取的快捷方式   代码可能偶尔产生令人惊讶的结果:一些变量你   声明可能根本不存在;控制流可能会短暂地移动到哪里   你没想到的;某些陈述可能无法执行,因为   他们计算出不变的结果,或者他们的价值已经存在;   有些陈述可能在不同的地方执行,因为它们已经存在   走出了循环。

这意味着:

  

我会为您插入调试符号,但如果优化传递将其删除,我将不会尝试保留这些符号,您必须处理该问题

调试符号不会写入代码,而是写入另一个名为" debug section"甚至在运行时都没有加载(仅由调试器加载)。这意味着:没有代码更改。您不应该注意到代码执行速度的任何性能差异,但如果加载器需要处理更大的二进制文件或者如果它以某种方式考虑增加的二进制大小,您可能会遇到一些缓慢。您可能需要自己对应用程序进行基准测试,以便在特定情况下100%确定。

请注意,gcc 4.8中还有another option

  

-Og

     

优化调试体验。 -Og启用不会干扰调试的优化。它应该是标准编辑 - 编译 - 调试周期的优化级别,提供合理的优化级别,同时保持快速编译和良好的调试体验。

此标志影响性能,因为它会禁用任何会干扰调试信息的优化传递。

最后,可能甚至会发生某些优化更适合特定体系结构而非另一个体系结构,除非指示您针对特定处理器执行此操作(请参阅march/mtune选项)体系结构),在O3 gcc中,最适合通用架构。这意味着在某些人为的场景中,你甚至可能会遇到O3比O2慢的情况。 "尽力而为"并不总是意味着"最好的"。