c++ - 使用 SSD 加快编译时间

Question

我想尝试加快 C++ 项目的编译时间。他们有大约 300 万行代码。

当然，我并不需要总是编译每个项目，但有时有很多源文件被别人修改，我需要全部重新编译(例如，当有人更新 ASN.1 源文件时)。

我测量过编译一个中间项目(不涉及所有源文件)大约需要三分钟。我知道这并不过分，但有时等待编译真的很无聊..

我尝试将源代码移动到 SSD(旧的 OCZ Vertex 3 60 GB)，经过基准测试，它比 HDD 快 5 到 60 倍(尤其是在随机读/写方面)。无论如何，编译时间几乎相同(可能快 2-3 秒，但应该有机会)。

也许将 Visual Studio bin 移到 SSD 会带来额外的性能提升？

只是为了完成问题:我有 W3520 Xeon @2.67 GHz 和 12 GB DDR3 ECC。

Answer 1

这在很大程度上取决于您的构建环境和其他设置。例如，在我的主编译服务器上，我有 96 GiB 的 RAM 和 16 个内核。 HDD 相当慢，但这并不重要，因为所有内容都缓存在 RAM 中。

在我的桌面(有时我也会编译)上，我只有 8 Gib 的 RAM 和六个内核。在那里进行相同的并行构建可能会大大加快速度，因为并行运行的六个编译器会占用足够的内存，以使 SSD 速度差异非常明显。

影响构建时间的因素有很多，包括 CPU 与 I/O“绑定(bind)”的比率。根据我的经验(在 Linux 上为 GCC)，它们包括:

• 代码的复杂性。大量元模板使其使用更多 CPU 时间，更多类似 C 的代码可能会使生成对象的 I/O(更多)占主导地位
• 临时文件的编译器设置，例如 GCC 的 -pipe。
• 正在使用优化。通常，优化程度越高，CPU 工作就越占主导地位。
• 并行构建。一次编译一个文件可能永远不会产生足够的 I/O 来使当今最慢的硬盘达到任何极限。然而，一次编译八个(或更多)内核可能会。
• 正在使用的操作系统/文件系统。似乎过去的一些文件系统对并行构建的许多文件的访问模式感到窒息，基本上将 I/O 瓶颈置于文件系统代码中，而不是底层硬件。
• 可用于缓冲的 RAM。操作系统缓冲 I/O 的力度越大，HDD 速度就越不重要。这就是为什么有时 make -j6 会比 make -j4 慢，尽管有足够的空闲内核。

简而言之:这取决于足够多的事情来做出任何“是的，它会帮助你”或“不，它不会帮助你”的纯粹猜测，所以如果你有机会尝试一下，那就去做吧.但是不要花太多时间在它上面，每尝试将编译时间减半，试着估计一下你(或你的同事，如果你有的话)重建项目的频率，以及它与可能节省的时间。