如何在VS2005中提高大型C++应用程序的链接性能

Question

我们有相当大的C++应用程序,它由Visual Studio 2005中的大约60个项目组成.目前在Release模式下链接需要7分钟,我想尝试减少时间.有没有改善链接时间的提示？

大多数项目都编译为静态库,这使得测试更容易,因为每个项目都有一组相关的单元测试.似乎静态库的使用阻止VS2005使用增量链接,因此即使打开增量链接,它也会每次都进行完整链接.

将DLL用于子项目会有什么不同吗？我真的不想通过所有的标题和添加宏来导出符号(甚至使用脚本),但如果它会做一些事情来减少7分钟的链接时间,我一定会考虑它.

出于某种原因,使用命令行中的nmake稍快一些,并且在Linux(使用GCC)上链接相同的应用程序要快得多.

• Visual Studio IDE 7分钟
• Visual C++使用命令行中的nmake - 5分钟
• Linux上的GCC 34秒

Answer 1

如果您使用该/GL标志启用整个程序优化(WPO)或/LTCG启用链接时间代码生成的标志,则将其关闭将显着缩短链接时间,但会牺牲一些优化.

此外,如果您使用/Z7标志将调试符号放在.obj文件中,您的静态库可能很大.如果阻止链接器从磁盘读取所有调试符号,则使用/Zi创建单独的.pdb文件可能会有所帮助.我不确定它是否确实有帮助,因为我没有对它进行基准测试.

Answer 2

请参阅我在Microsoft提出的建议:https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx？反馈ID = 511300

你应该投票支持它!这是我对它的最后评论:

是的,我们正在使用增量链接来构建我们的大多数项目.对于最大的项目,它没用.事实上,将这些项目与增量链接相关联需要花费更多的时间(2分50秒与2分44秒相比).我们观察到当ILK文件的大小很大时它不起作用(我们最大的项目在win 32中产生了262144 KB).

贝娄,我列出了其他我们试图减少链接时间的事情:

• 显式模板实例化以减少代码膨胀.收益微薄.
• IncrediLink(IncrediBuild为编译提供了有趣的收获,但链接几乎没有收获).
• 删除很少调试的库的调试信息(良好的增益).
• 删除«Pre-Build Event»中的PDB文件(奇怪的是它给出了有趣的增益:2分44而不是3分34).
• 将许多静态库转换为DLL.重要的收获.
• 使用配备大量RAM的计算机,以最大化磁盘缓存.最大的收获.
• 大obj与小obj.没有不同.
• 更改项目选项(/ Ob1,/ INCREMENTAL,启用COMDAT折叠,嵌入清单等).有些人给了其他有趣的收获.我们尝试不断最大化我们的设置.
• 最大化内部链接与外部链接.这是一个很好的编程实践.
• 尽可能多地分离软件组件.您可以在快速链接的单元测试中工作.但是我们仍然必须将事物整合在一起,我们有遗留代码,我们使用第三方组件.
• 使用secret linker switch/expectedoutputsize:120000000.收益微薄.

请注意,对于我们所有的实验,我们都仔细测量了链接时间.缓慢的链接时间严重影响生产力.当你实现复杂的算法或跟踪困难的bug时,你想快速迭代这个序列:修改一些代码,链接,跟踪调试,修改一些代码,链接等...

优化链接时间的另一点是它对我们的持续集成周期的影响.我们有许多共享公共代码的应用程序,我们正在运行持续集成.我们所有应用程序的链接时间缩短了一半的周期时间(15分钟)......

在线程https://blogs.msdn.microsoft.com/vcblog/2009/09/10/linker-throughput/中,提出了一些有趣的建议来改善链接时间.在64位计算机上,为什么不提供在RAM中完全使用文件的选项？

同样,欢迎任何有助于我们缩短链接时间的建议.

Answer 3

通常,使用DLL而不是静态库将大大缩短链接时间.