有一种技术在过去对我来说非常有效:不要独立编译多个c++源文件，而是生成一个包含所有其他文件的c++文件，就像这样:

// myproject_all.cpp
// Automatically generated file - don't edit this by hand!
#include "main.cpp"
#include "mainwindow.cpp"
#include "filterdialog.cpp"
#include "database.cpp"

当然，这意味着您必须重新编译所有包含的源代码，以防任何源代码发生更改，因此依赖关系树变得更糟。但是，将多个源文件编译为一个翻译单元更快(至少在我使用MSVC和GCC的实验中)，并且生成更小的二进制文件。我还怀疑编译器被赋予了更大的优化潜力(因为它可以一次看到更多代码)。

这种技术在各种情况下都会失效;例如，如果两个或多个源文件声明了同名的全局函数，编译器就会退出。我在其他答案中找不到这个技巧，这就是为什么我在这里提到它。

不管怎样，KDE项目从1999年起就使用了这种完全相同的技术来构建优化的二进制文件(可能是为了发布)。转换到构建配置脚本的过程叫做——enable-final。出于对考古的兴趣，我翻出了宣布这个功能的帖子:http://lists.kde.org/?l=kde-devel&m=92722836009368&w=2

更大的内存。

有人在另一个回答中谈到了RAM驱动器。我用80286和Turbo c++(显示年龄)做到了这一点，结果是惊人的。就像机器崩溃时数据丢失一样。

如果您有一个多核处理器，Visual Studio(2005及以后版本)和GCC都支持多处理器编译。当然，如果你有硬件，这是可以实现的。

当我从大学毕业时，我看到的第一个真正有生产价值的c++代码有这些神秘的#ifndef…#endif指令在它们之间定义头文件的地方。我以一种非常天真的方式问了那个写代码的人关于这些重要的东西，他被介绍给了大规模编程的世界。

回到正题，当谈到减少编译时间时，使用指令来防止重复的头定义是我学到的第一件事。

来自微软:https://devblogs.microsoft.com/cppblog/recommendations-to-speed-c-builds-in-visual-studio/

具体建议包括:

项目使用PCH吗 是否包含常用的系统、运行时和第三方头文件 PCH 在PCH中包含很少改变项目特定的头 不包括经常变化的头 是否定期审核PCH以保持产品流失的最新情况 使用/ mp 是否移除/Gm以支持/MP 是否解决与#import和use /MP的冲突 是否使用连接器开关/增量 使用链接器开关/调试:fastlink 是否考虑使用第三方构建加速器

在Linux(也许还有其他一些* nix)上，您可以通过不盯着输出并更改到另一个TTY来加速编译。

下面是实验:printf使我的程序变慢