我们的解决方案包含100多个项目，超过8000个cpp文件和超过10个＆＃39000个头文件。
我试图改善我们的构建时间。
解决方案中的一个项目只包含5个cpp文件，编译大约需要10秒。头文件最初包含在cpp文件中，但是为了准备切换预编译头文件，我将包括移动到一个pch.h文件中。
现在每个cpp文件都包含pch.h文件。
这本身并没有对编译时间做出任何明显的改变 - 它仍然只有10秒钟。
现在，当我告诉项目实际使用pch文件作为预编译头时，编译项目需要17秒。
为什么预编译包含的标题会使项目构建的时间比文件只是每个cpp文件的#included一样？
更多信息。
我们使用一种名为＆＃34; lumping＆＃34; - （单个cpp文件不是单独编译的 - 它们每个#included包含在一个项目范围的cpp文件中，这是唯一编译的cpp文件。）
根据＆＃34;显示包含＆＃34;以及它的价值，感谢意大利面条代码。 pch文件中的十几个包含文件导致包含大约3000（！）个文件。显然，这需要修复！
编译时预编译的头文件大约为130Mb。
如果我们关闭集总，单个项目构建（不是整个解决方案）需要45秒。如果我们然后打开预编译头，则构建时间会改善。
我可能错过了显而易见的问题，但是为什么当开启lumping时，开启预编译的标头会减慢构建速度吗？
答案 0 :(得分：1)
PCH做的是＆＃34;预处理＆＃34; /＆＃34;预编译＆＃34; 多个源文件包含的公共标题上的阶段。这有助于重复＆＃34;预处理＆＃34; /＆＃34;预编译＆＃34;避免了，编译器为每个源文件加载其先前的状态。
如果您只有一个大的源文件，那么＆＃34;预处理＆＃34; /＆＃34; procompiling＆＃34;也需要发生，但总共只有一次。因此，保存和加载PCH文件会引入开销，而不会带走（因为没有任何重复）。
我使用术语＆＃34; preprocess＆＃34; /＆＃34; precompile＆＃34;这里因为PCH的执行方式根据您的编译器而有很大差异，并且可能更倾向于其中一个。
现在，除非你在很多代码中使用像Boost这样繁重的模板库，否则通常足以清理包含依赖项以加快编译时间，这通常是非常重要的因素。但这需要维护。