什么是Windows平台上最快的C++链接器？

Question

显然，Visual Studio 2010中C++链接器的速度并没有得到很大提升（在我们的情况下只有约25%）。这意味着我们仍然被困在30秒至两分钟的链接时间范围内。肯定有更好的链接器吧？有没有人尝试过切换到另一个链接器甚至是完整的工具集，看看链接时间是否会急剧下降？

谢谢,

Sebastiaan

- Sebastiaan M

---

两分钟听起来不算太多。好的一面是你可以花时间访问SO。 - dalle

我同意两分钟并不是一个大问题，但它比某些神奇的秒数（我相信大约是十秒钟左右）要更长，确实会让你想知道你可以做些什么而不是等待。因此，每次链接都会使你失去注意力。与C#中的TDD相比，链接时间很短，你可以保持流畅。如果我们也能在C++中拥有这样紧密的循环，那将是非常好的。 - Sebastiaan M

也许你可以在每个编辑/编译/调试周期中尝试修复多个错误？ :-) - paxdiablo

Answer 1

您可能会找到一个更快的链接器，但除非它的速度是当前的十倍且我每小时需要链接三十次，否则我更愿意使用Microsoft经过测试的工具。

相对较慢的链接时间也比潜在不稳定的软件更好。

而如今的年轻人真是被宠坏了。在我那个年代，我们必须将80列卡片提交给计算机中心，如果我们很“幸运”，操作员会在下周四之前把它们打出来，然后我们才能开始从硬拷贝输出进行调试 :-)

- paxdiablo

---

很高兴事情自那时以来得到了发展！;) - ereOn

Answer 2

当我们检查链接器速度时，我们发现磁盘速度是最大的限制因素。文件流量非常大，特别是由于调试信息（只需检查pdb文件的大小）。

对我们来说，解决方案是：

• 安装大量RAM，以便可以缓存大量文件流量（如果您使用的是64位操作系统，请选择4GB或更多）。注意：您可能需要更改一些系统设置，以便系统能够为缓存分配更多的内存
• 使用非常快的硬盘（连接多个硬盘作为RAID可能会更有帮助）

我们还尝试过SSD，但我们尝试过的SSD写入性能非常慢，因此净效果是负面的。这可能已经改变了，特别是在最好的SSD中。

首先，我建议启动进程资源管理器（甚至任务管理器也可以），并在链接阶段期间检查CPU负载和I/O流量，以便您可以验证您是否受到CPU限制或I/O限制。

- Suma

---

你尝试过在内存充足的机器上使用RAM磁盘吗？ - Georg Fritzsche

不，我们没有。我认为适当的缓存应该有几乎相同的效果（写入都是在后台完成的），但我可能很容易就错了。一旦我们升级了硬件（快速硬盘驱动器+大内存），这个问题对我们来说就不再重要了，我们也没有动力去尝试更多的改进。 - Suma

Answer 3

可能有一些改进，但我想你所说的改进幅度只有几个百分点。你不太可能找到任何速度快得多的东西（我想这就是你想要的）。

不过，有办法可以提高链接时间。您打开了哪些选项？像“启用增量链接”和“启用函数级链接”之类的选项可以对链接性能产生巨大影响（显然，第一次链接时它将是一个“完整”的链接，但使用这些设置进行后续链接可以更快地完成）。

- Dean Harding

---

我们已关闭所有那些讨厌的链接器选项，尽可能以“正常”的方式进行链接。:) Visual Studio 链接器的缓慢是由生成 pdb 引起的。如果我们去掉 /debug，链接将会很快。我希望有一种链接器能够更智能地（并行）生成调试信息。 - Sebastiaan M

@Sebastiaan：按任何标准来看，那些链接器选项都不算恶劣。 - rwong

关闭链接时代码生成（LTCG），因为它是选项中最慢的。 - rwong

@rwong：对于大型项目来说，增量链接确实很麻烦。对我们而言，它成功的概率只有10%，但链接时间可以减少约75%；而90%的情况下它都不起作用，反而会使链接时间至少增加200%。 - Sebastiaan M

@Sebastiaan：看起来是VS2010的一个bug。请在Microsoft Connect上提交一个错误报告。（免责声明：我与微软无关。） - rwong

Answer 4

当我的链接时间超过10秒时，我会感到紧张。

使用现代风格的SSD硬盘。我有2个60GB的OCZ Vertex2 E硬盘作为RAID 0，IO不再是问题。即使进行大量写操作，SSD现在也足够适合日常使用。

并且获得几个千兆字节的内存。现在没有理由使用少于8GB的RAM。

- Lothar

Answer 5

开启增量链接，链接不应超过1秒钟。

- teh expert