1

当使用可以在 C 中并行执行的代码编写程序时,我们肯定会使用O 标志来优化代码。

gcc -Olevel [options] [source files] [object files] [-o output file]

在大型项目中,我们通常将代码拆分成几个文件。我没有找到答案的问题是:

由于我们将代码拆分为文件并且O标志没有足够的信息来进一步优化,程序的性能是否会下降?有这种可能吗?

4

2 回答 2

2

当您将代码分解为单独的文件时,它可能会将其拆分为多个翻译单元,编译器通常无法对其进行优化。

以在一个翻译单元中定义但在许多其他翻译单元中引用的常量为例。所有引用常量的计算都必须在运行时执行,因为常量不能在编译时折叠到它们中。

链接时优化( -flto) 是绕过限制的一种方法。

于 2015-10-30T20:03:16.877 回答
1

单机优化

只是为了补充@Jason 的回答,我想发布另一种技术来避免拆分文件时出现的限制。

它被称为单单元优化

单一编译单元技术使用预处理器指令在编译时而不是在链接时将不同的翻译单元“粘合”在一起。由于消除了重复,这减少了总体构建时间,但增加了增量构建时间(对包含在单个编译单元中的任何单个源文件进行更改后所需的时间),因为需要完全重建如果任何单个输入文件发生更改,则整个单元。

整个项目,即使在文件中拆分,也可以优化,就好像程序的所有部分对编译器都是可见的,而不需要用户再次合并文件。

如何应用它?

通常,该项目将包含一个带有 main 的文件,并将包含每个拆分文件的所有头文件:

主程序

#include "sub-program-1.h"
#include "sub-program-2.h"
...
#include "sub-program-n.h"
//rest of code

其中每个.h文件都对应于其各自.c编译的文件(可能通过makefile)。

为了应用 SCU,我们删除了我上面提到的包含,而是创建了一个新文件(我们称之为SCU.c)。这将是以下内容。

SCU.c

#include "sub-program-1.c"
#include "sub-program-2.c"
...
#include "sub-program-3.c"
#include "main.c"
//no more code in this file

而要编译整个项目,我们只需编译SCU.c

于 2015-11-06T14:15:27.630 回答