使用-g gcc标志编译的程序是否比不使用-g编译的程序慢? [英] Is a program compiled with -g gcc flag slower than the same program compiled without -g?

问题描述

我正在用-O3编译程序，以提高性能，用-g编译调试符号(如果发生崩溃，我可以使用核心转储).一件事让我很困扰，-g选项是否会导致性能下降?当查看带有-g和不带有-g的编译的输出时，我发现不带有-g的输出比带有-g的编译的输出小80％.如果多余的空间用于调试符号，我不会在意(我想)，因为这部分在运行时未使用.但是，如果对于不带-g的编译输出中的每条指令，我都需要在带-g的编译输出中执行4条指令，而不是我肯定更喜欢停止使用-g选项，即使这样做是因为无法处理核心转储./p>

如何知道程序内部调试符号部分的大小，并且通常使用-g编译会比不使用-g编译相同代码的程序运行得慢?

解决方案

从

请注意，还有另一种选择来自gcc 4.8:

-Og

优化调试体验. -Og 启用不干扰调试的优化.它应该是标准edit-compile-debug周期的优化级别选择，在保持快速编译和良好调试体验的同时，提供合理的优化级别.

此标志 将影响性能，因为它将禁用任何会干扰调试信息的优化过程.

最后，可能有甚至发生的一些优化更适合于特定体系结构而不是另一种体系结构的情况，除非针对您的特定处理器进行了说明(请参见march/mtune 选项架构)，在O3中，gcc会在通用架构上尽其所能.这意味着在某些人为情况下，您甚至可能会遇到O3比O2慢的情况.尽力而为"并不总是意味着最有可能".

I'm compiling a program with -O3 for performance and -g for debug symbols (in case of crash I can use the core dump). One thing bothers me a lot, does the -g option results in a performance penalty? When I look on the output of the compilation with and without -g, I see that the output without -g is 80% smaller than the output of the compilation with -g. If the extra space goes for the debug symbols, I don't care about it (I guess) since this part is not used during runtime. But if for each instruction in the compilation output without -g I need to do 4 more instructions in the compilation output with -g than I certainly prefer to stop using -g option even at the cost of not being able to process core dumps.

How to know the size of the debug symbols section inside the program and in general does compilation with -g creates a program which runs slower than the same code compiled without -g?

解决方案

Citing from the gcc documentation

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops.

that means:

I will insert debugging symbols for you but I won't try to retain them if an optimization pass screws them out, you'll have to deal with that

Debugging symbols aren't written into the code but into another section called "debug section" which isn't even loaded at runtime (only by a debugger). That means: no code changes. You shouldn't notice any performance difference in code execution speed but you might experience some slowness if the loader needs to deal with the larger binary or if it takes into account the increased binary size somehow. You will probably have to benchmark the app yourself to be 100% sure in your specific case.

Notice that there's also another option from gcc 4.8:

-Og

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

This flag will impact performance because it will disable any optimization pass that would interfere with debugging infos.

Finally, it might even happen that some optimizations are better suited to a specific architecture rather than another one and unless instructed to do so for your specific processor (see march/mtune options for your architecture), in O3 gcc will do its best for a generic architecture. That means you might even experience O3 being slower than O2 in some contrived scenarios. "Best-effort" doesn't always mean "the best available".

这篇关于使用-g gcc标志编译的程序是否比不使用-g编译的程序慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！