如何提高大型C++；VS2005中的应用 我们有相当大的C++应用程序，它由Visual Studio 2005中的大约60个项目组成。它目前需要7分钟，以释放模式链接，我想尝试减少时间。有没有改进链接时间的技巧

大多数项目都编译成静态库，这使得测试更容易，因为每个项目都有一组相关的单元测试。静态库的使用似乎阻止了VS2005使用增量链接，因此即使启用了增量链接，每次都会执行完整链接

在子项目中使用DLL会有什么不同吗？我不想通过所有的标题和添加宏来导出符号（甚至使用脚本），但是如果它能减少7分钟的链接时间，我当然会考虑它。 出于某种原因，从命令行使用nmake稍微快一点，并且在Linux上链接同一应用程序（使用GCC）要快得多

• Visual Studio IDE 7分钟
• Linux上的GCC 34秒

---

60个libs到link的链接听起来确实很少。这可能有点极端，但它可能会从根本上加快速度。创建一个包含几个项目的新解决方案，并将现有项目中的所有源添加到这些解决方案中。然后构建并链接它们，只保留小的用于测试。

使用一台具有多个处理器的更快的计算机，并启用并行构建（默认情况下，此选项可能处于启用状态）。要允许最大程度的并行，请确保您的项目依赖项是正确的，并且没有不必要的依赖项。

我不认为转换为DLL会有用。

---

您可以尝试寻找与优化相关的选项，并将其关闭。链接器可能会花费很长时间在libs上查找它可以消除的冗余代码。你的应用程序可能会变大或变慢，但这对你来说可能不是问题。

一般来说，使用DLL而不是静态库会大大缩短链接时间。

请看Xoreax。它的分布式编译大大缩短了我们的完整构建/链接时间，从大约40分钟缩短到8分钟

---

此外，该产品还具有一个他们称之为的功能，该功能可以帮助您获得增量链接，甚至可以使用静态链接库

有几个人报告（我自己也注意到）修改静态链接库中的文件将禁用整个解决方案的增量链接；这似乎就是你所看到的。有关这方面的一些信息，请参见评论和

---

一种解决方法是使用外接程序。这可能需要对您的工作区进行一些更改，但回报绝对值得。对于商业解决方案，请使用Xoreax，它基本上采用了相同的技术，但也添加了其他功能。我很抱歉，如果我听起来像是一个不可信构建的推销员，我只是一个非常满意的客户。

如果你真的在谈论链接时间，那么像fast solution build和Xoreax这样的东西不会真的有多大帮助（除了不可信构建）。假设您真的在测量从开始到结束的链接，那么我建议您拥有的LIB的数量就是问题所在

在加载所有对象和库文件时，链接阶段至少在最初是IO绑定的。您可能会遇到这样的情况，即您有60个库以及一些大量.obj文件的主项目。我猜想您可能只是看到了，至少部分地，windows加载所有这些libs和.obj文件时的典型缓慢

你可以很容易地测试这个。获取所有这些lib文件并构建一个lib文件作为测试。与其链接60个，不如链接一个，看看你的时间都花在哪里了。那会很有趣

---

NTFS是出了名的慢。Linux上的速度不应该是7米而不是32秒，但这可能是问题的一部分。使用DLL将有所帮助，但您将遭受应用程序启动时间的损失，尽管这不会早到糟糕的地步。我相信你不会有7M的应用程序启动时间。

< P>我以前有过类似的应用程序连接VisualC++的问题。在我的例子中，我只是没有足够的可用RAM，过多的磁盘分页正在减慢链接过程，使其停止。将我的RAM从1GB加倍到2GB带来了巨大的改进。您的dev box运行了多少钱？

您可以尝试查看以下内容：

基本上，如果您有多个内核，您可以并行运行项目构建。

如果您使用标志来启用整个程序优化（WPO）或标志来启用链接时代码生成，则关闭它们将显著提高链接时间，但会牺牲一些优化

---

此外，如果您使用该标志将调试符号放入

.obj

文件中，那么您的静态库可能非常庞大。如果使用创建单独的

.pdb

文件会阻止链接器从磁盘读取所有调试符号，则可能会有所帮助。我不确定它是否真的有用，因为我还没有对它进行基准测试。

我刚刚发现，我们在头文件中意外地定义了一个大的字符串表，它几乎包含在每个（静态）库中。（我正在谈论一个巨大的C++项目）当链接器创建了EXE时，它看起来像表的统一（只有一个在EXE中结束）或者LIBS的解析永远被占用。将表放在一个单独的C++文件中，在相对较慢的机器上花费几分钟的链接。

---

不幸的是，除了偶然的机会，我不知道如何找到类似的东西。

对于调试版本，可以使用增量链接，这可以大大提高链接时间

可悲的是，存在某些陷阱，VS2005不会警告您

• 如果使用静态库