使用SSD加快编译时间

Question

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

当然，我不需要总是编译每个项目，但有时会有很多源文件被其他人修改，我需要重新编译所有这些文件（例如，当有人更新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个内核。硬盘相当慢，但这并不重要，因为所有内容都缓存在RAM中。

在我的桌面上（我有时也编译）我只有8个内存和六个内核。做同样的并行构建可能会大大加快，因为并行运行的六个编译器会占用足够的内存，因此SSD的速度差异非常明显。

有许多因素影响构建时间，包括CPU与I / O“边界”的比率。根据我的经验（Linux上的GCC），它们包括：

• 代码的复杂性。很多metatemplates使得它使用更多的CPU时间，更多类似C的代码可能会使生成的对象的I / O（更多）占主导地位
• 临时文件的编译器设置，例如GCC的-pipe。
• 正在使用的优化。通常，优化程度越高，CPU工作占主导地位越多。
• 并行构建。一次编译一个文件可能永远不会产生足够的I / O来获得今天最慢的硬盘到任何限制。但是，可能会同时使用八个核心（或更多核心）进行编译。
• 正在使用的OS /文件系统。似乎过去的一些文件系统已经扼杀了并行构建的许多文件的访问模式，实质上是将I / O瓶颈放入文件系统代码中，而不是底层硬件。
• 可用于缓冲的RAM。操作系统可以更积极地缓冲I / O，硬盘速度越不重要。这就是为什么有时候make -j6可能比make -j4慢，尽管有足够的空闲核心。

简而言之：取决于足够的事情来做出任何“是的，它会帮助你”或“不，它会帮助你”纯粹的猜测，所以如果你有可能试一试，那就去做吧。但是不要花太多时间在上面，因为你试图将编译时间缩短到一半，试着估计你（或你的同事，如果你有的话）可以重建项目的频率，以及它与节省了可能的时间。

Answer 2

C ++编译/链接受处理速度的限制，而不受HDD I / O的限制。这就是为什么你没有看到编译速度的任何增加。 （将编译器/链接器二进制文件移动到SSD将不会执行任何操作。编译大型项目时，编译器/链接器和必要的库将被读入内存一次并保留在那里。）

在编译C项目时，我已经看到了将工作目录移动到SSD或ramdisk的一些小的加速（这比使用大量模板等的C ++项目耗时少得多），但还不足以使其值得它

Answer 3

我发现，当代码在SSD（具有8核Core i7，12 GB RAM的系统）上时，编译大约100万行C ++的项目加速了大约两倍。实际上，我们获得的最佳性能是系统的一个SSD和源的第二个 - 这不是构建速度快得多，但是当大型构建正在进行时，操作系统响应更快。 / p>

另一件带来巨大变化的事情是实现并行建设。请注意，需要启用两个单独的选项：

• 菜单工具→选项→项目和解决方案→最大并行项目构建数
• 项目属性→ C ++ /常规→多处理器编译

多处理器编译与其他几个标志不兼容（我认为包括最小重建），因此请检查输出窗口是否有警告。我发现使用MP编译标志设置所​​有内核都接近100％负载，所以你至少可以看到CPU被积极使用。

Answer 4

未提及的一点是，在使用ccache和高度并行构建时，您会看到使用SSD的好处。

Answer 5

我确实用SSD替换了我的硬盘驱动器，希望它能缩短我的C ++项目的编译时间。简单地用SSD替换硬盘驱动器并没有解决问题，两者的编译时间几乎相同。

然而，在最初的失败之后，我成功地将编译加速了大约六次。

完成以下步骤以提高编译速度。

1. 关闭休眠状态：＆＃34; powercfg -h off＆＃34;在命令提示符

2. 关闭C驱动器上的驱动器索引

3. 收缩页面文件最多800分钟/ 1024（最初设置为系统管理大小8092）。