从Visual Studio 2017开始，你可以有一些编译器度量需要花费的时间。

将这些参数添加到项目属性窗口中的C/ c++ ->命令行(附加选项): /Bt+ /d2cgsummary /d1reportTime . /Bt+ /d2cgsummary /d1reportTime . /

你可以在这篇文章中获得更多信息。

更快的硬盘。

编译器将许多(可能很大)文件写入磁盘。使用SSD而不是典型的硬盘，编译时间要低得多。

以下是一些例子:

通过启动一个多编译作业(make -j2就是一个很好的例子)来使用所有处理器内核。 关闭或降低优化(例如，GCC使用-O1时比使用-O2或-O3时快得多)。 使用预编译的头文件。

更大的内存。

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

有一种技术在过去对我来说非常有效:不要独立编译多个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

我将链接到我的另一个答案:如何减少Visual c++项目(原生c++)的编译时间和链接时间?我想补充的另一点是使用预编译的头文件，这经常会导致问题。但是，请只将它们用于几乎不会改变的部分(如GUI工具箱头)。否则，他们会花费你更多的时间，而不是他们最终节省你的时间。

另一个选项是，当你使用GNU make时，打开-j<N>选项:

  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.

我通常把它设置为3，因为我这里有一个双核。然后，它将为不同的翻译单元并行运行编译器，前提是它们之间没有依赖关系。链接不能并行完成，因为只有一个链接器进程将所有目标文件链接在一起。

但是链接器本身可以被线程化，这就是GNU gold ELF链接器所做的。它是优化的多线程c++代码，据说它链接ELF对象文件的速度比旧的ld快很多(实际上包含在binutils中)。