我想尝试加快 C++ 项目的编译时间。他们有大约 300 万行代码。
当然，我不需要总是编译每个项目，但有时有很多源文件被其他人修改过，我需要重新编译所有这些文件（例如，当有人更新一个项目时）ASN.1 https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One源文件）。
我测量过编译一个中期项目（不涉及所有源文件）大约需要三分钟。我知道这并不算太多，但有时等待编译真的很无聊。
我尝试将源代码移至 SSD（旧的 OCZ Vertex 3 60 GB），经过基准测试，它比 HDD 快 5 到 60 倍（尤其是在随机读/写方面）。无论如何，编译时间几乎相同（可能快 2-3 秒，但这应该是一个机会）。
也许将 Visual Studio bin 移至 SSD 会带来额外的性能提升？
只是为了完成这个问题：我有一个 W3520 Xeon @2.67 GHz 和 12 GB DDR3 ECC。
这在很大程度上取决于您的构建环境和其他设置。例如，在我的主编译服务器上，我有 96 GiB 的 RAM 和 16 个内核。 HDD 相当慢，但这并不重要，因为所有内容都缓存在 RAM 中。
在我的台式机上（有时我也进行编译），我只有 8 Gib RAM 和 6 个内核。在那里进行相同的并行构建可能会大大加快速度，因为并行运行的六个编译器会占用足够的内存，导致 SSD 速度差异非常明显。
有很多因素会影响构建时间，包括 CPU 与 I/O“边界”的比率。在我的经验中 （GCC http://en.wikipedia.org/wiki/GNU_Compiler_Collection在 Linux 上）它们包括：
- 代码的复杂性。许多元模板使其使用更多的 CPU 时间，更多类似 C 的代码可能会使生成对象的 I/O（更多）占主导地位
- 临时文件的编译器设置，例如
-pipe对于海湾合作委员会。
- 正在使用优化。通常，优化越多，CPU 工作就越占主导地位。
- 并行构建。一次编译一个文件可能永远不会产生足够的 I/O 来使当今最慢的硬盘达到任何限制。然而，同时使用八个核心（或更多）进行编译可能会这样。
- 正在使用的操作系统/文件系统。过去的一些文件系统似乎因并行构建的许多文件的访问模式而陷入困境，本质上将 I/O 瓶颈置于文件系统代码中，而不是底层硬件中。
- 可用于缓冲的 RAM。操作系统缓冲 I/O 的能力越强，HDD 速度就越不重要。这就是为什么有时
make -j6可能比 a 慢make -j4尽管有足够的空闲核心。
简而言之：这取决于足够多的事情来做出任何“是的，它会帮助你”或“不，它不会帮助你”的纯粹猜测，所以如果你有可能尝试一下，那就去做吧。但是不要花太多时间在这上面，每每小时你尝试将编译时间减少一半，尝试估计你（或你的同事，如果有的话）可以重建项目的频率，以及这与可能节省的时间。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
