使用可以在C中并行执行的代码编写程序时，我们肯定会使用O flags来优化代码。
gcc -Olevel [options] [source files] [object files] [-o output file]
在大型项目中，我们通常split the code into several files。我的问题，我找不到答案，是：
程序的性能是否会下降，因为我们将代码拆分为文件而O标志没有足够的信息来进一步优化？有没有这种可能性？
答案 0 :(得分：2)
当您将代码分解为单独的文件时，它可能会将其拆分为多个转换单元，编译器通常无法对其进行优化。
例如，在一个翻译单元中定义一个常量，但在许多其他单元中引用。所有引用常量的计算都必须在运行时执行，因为常量不能在编译时折叠到它们中。
链接时optimization（-flto）是解决限制的一种方法。
答案 1 :(得分：1)
为了补充@Jason的回答，我想发布另一种技术来避免分割文件时出现的限制。
它名为 Single Unit Optimization ：
单编译单元技术使用预处理器指令＆＃34; glue＆＃34;不同的翻译单元在编译时而不是在链接时。由于消除了重复，这减少了总体构建时间，但增加了增量构建时间（对单个编译单元中包含的任何单个源文件进行更改后所需的时间），因为需要如果任何单个输入文件发生更改，则完全重建整个单元。
整个项目，即使在文件中拆分，也可以进行优化，就像程序的所有部分一次对编译器可见，而不需要用户再次合并文件。
通常，项目将包含一个带main的文件，并包含每个拆分文件的所有头文件：
<强>的main.c
#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