很长的编译时间

Question

我正在开发一个包含数千个源文件的大型解决方案，其中一些可能因为使用Boost和依赖性问题而有超过一千个包含。在12核Xeon E5-2690 v2机器（Windows 7）上并行编译时，使用Waf 1.7.13重建解决方案需要4个小时。我该怎么做才能加快速度？

Answer 1

我想到的一些事情：

• 使用转发声明和PIMPL。
• 检查您的代码库，看看当正常的类或函数已经足够时，您是否创建了不必要的模板。
• 尝试在适用时在void*上运行的非通用实施实施您自己的模板，模板仅用作类型安全包装（参见＆＃34;第42项） ：明智地使用私有继承和＃34;更有效的C ++＆＃34;一个很好的例子。）
• 查看编译器的文档，了解预编译标题。
• 重构您的应用程序的整个架构，以便更多内部库和更小的应用程序层，目标是从长远来看，库变得如此稳定，以至于您不会; t必须一直重建它们。
• 使用优化标记进行试验。看看你是否可以在几个特定的​​编译单元中关闭优化，在这些单元中，优化不会在执行速度或二进制大小方面产生可测量的差异，但会显着增加编译时间。

Answer 2

如果不能重构删除依赖项，并且构建体系结构太不可靠，您必须不时地清理和重建所有内容（在一个完美的世界中，这绝不应该发生），您可以：

• 改进您的机器：使用SSD硬盘和/或大量RAM。如果项目有数千个源文件，则需要多次访问磁盘，并进行随机但可缓存的访问。对于具有超线程的12核心机器，我建议使用不少于24gb的ram，可能更好地朝向32.你应该测量你的源代码大小是多少以及你可以并行运行的并发24个编译器使用了多少ram。 / LI>
• 使用编译器缓存。我不知道如何从Windows和你的构建系统设置这样的环境，所以我不能在这里提出太多建议。

Answer 3

罪魁祸首可能是项目本身的结构：重建的预期时间大致与源文件的数量与其包含的标题数量成正比。通过基于模板的强大编程，这种努力随着源文件的平方而增长。

因此，您有两个相反的选项可以缩短总编译时间：

1. 您减少了每个源文件包含的标头数。这意味着您必须避免使用模板的任何模板。尽量减少模板间的依赖关系。

2. 仅在标头中编程，仅使用单个.cpp文件，该文件会在应用程序中实例化所有不同的模板。这样可以避免重新编译标题。

   • 可能的变体是从项目中的所有头文件创建预编译头，这样预编译头就占用了大部分构建时间。

当然，选项2意味着没有增量构建这样的东西，每次编译时都需要重新编译整个项目。这可能会使您的项目完全无法维护。因此，我强烈建议选择选项1.但是这需要一种不同的编程风格（一种使用模板的模式非常谨慎），而不是您的项目似乎写入。

在任何一种情况下，都没有灵丹妙药：如果不重组整个项目，就不可能对编译时间做出重大改变。

Answer 4

您可以相对轻松地尝试一些建议：

1. 使用IncrediBuild或
使用分布式编译
2. 使用＆＃34;团结＆＃34;构建，即在单个cpp文件中包含几个cpp文件，并仅编译unity cpp（您可以使用一个简单的工具构建unity cpp，每个cpp文件中包含给定数量的cpp文件）。虽然我不喜欢这种技术，因为它的缺点我已经看到它经常用于物理结构不良的项目中以优化编译和放大。链接时间。
3. 使用＆＃34; #pragma一次＆＃34;在标题
4. 使用预编译的标题
5. 优化头文件中的冗余#include。我不知道是否有适合它的工具，但您可以轻松地构建一个工具，在标题中注释#includes并尝试编译它们以查看哪些不需要。
6. Profile #include文件编译速度，专注于解决表现最差的人和#include链中最深的人。即使用前向声明而不是#include＆＃39; s等
7. 购买更多/更好的硬件