我们这是在Visual Studio组成的约60个项目2005年。目前需7分钟发布模式联系起来，我想，以尽量减少时间相当大的C ++应用程序。 是否有改进的链接时任何提示？
大多数项目编译为静态库，这使测试更容易，因为每个人也有一组相关的单元测试。 看来使用静态库的防止VS2005使用增量链接，因此即使增量链接打开每次上它完全链接。
将使用的DLL的子项目有什么区别？ 我真的不想去通过所有的头，并添加宏导出的符号（甚至使用脚本），但如果它会做些什么来减少7分钟链接时，我肯定会考虑它。
对于使用NMAKE命令行的一些原因是速度稍快和链接Linux上的同一个应用程序（使用GCC）的速度要快得多。
如果您正在使用/GL标志，使整个程序优化（WPO）或/LTCG标志来启用链接时代码生成，将其关闭会显著提高链路倍，在一些优化的代价。
另外，如果您正在使用/Z7标志把调试符号在.obj文件，你的静态库可能是巨大的。 使用/Zi创建单独的.pdb如果防止连接器读取所有调试符号从磁盘文件可能有帮助。 我不知道，如果它实际上没有帮助，因为我还没有基准它。
看到我的建议，在微软提出： https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=511300
你应该选它！ 这是我在这最后的评论：
是的，我们正在使用增量链接建设我们的大多数项目。 对于最大的项目，也没用。 事实上，它需要更多的时间来这些项目与增量链接（2min50相比2min44）链接。 我们观察到，当ILK文件大小大（我们最大的项目产生262144 KB的32胜的ILK），这是行不通的。
贝娄，我列出了别人的东西，我们试图减少链接时间：
请注意，我们所有的实验中，我们精心测量的链接时。 慢速链接时生产力严重的成本。 当你实现复杂的算法或跟踪困难的错误，你想快速迭代序列：修改一些代码，链接，跟踪调试，修改一些代码，链接，等等。
优化链接时，另一点是对我们的持续集成周期的影响。 我们有共同的代码许多应用程序，我们在其上运行的持续集成。 我们所有的应用程序的链接时采取了周期的一半时间（15分钟）...
在线程https://blogs.msdn.microsoft.com/vcblog/2009/09/10/linker-throughput/ ，作了一些有趣的建议，以改善链接时间。 在64位电脑，为什么不提供一个选项，完全RAM与文件的工作？
再次，可以帮助我们减少链接时间任何建议是值得欢迎的。
通常，使用的DLL，而不是静态库将改善链接时间不少。
看看Incredibuild通过Xoreax。 其分布式编译显着来自大约40分钟缩短我们全力打造/链接倍至8分钟。
此外，该产品具有人们常说的功能Incredilink这应有助于你得到静态链接库，甚至工作的增量环节。
我不认为转换成DLL文件将是有益的。 你可以尝试寻找选项做优化，将其关闭。 链接器可能会花费很长的时间寻找在库的冗余代码，它可以消除。 您的应用程序最终可能会更大或更慢，但是这可能不是一个问题给你。
有几个人报告（和我本人也注意到），在静态链接库修改的文件，将禁用整个解决增量链接; 这似乎是你所看到的。 看评论在这里和这里有关的一些信息。
一种解决方法是使用快速的解决方案生成外接。 这可能包括让您的工作区一些变化，但回报是绝对值得的。 对于一个商业解决方案，使用Xoreax的Incredibuild ，基本上采用了相同的技术，但增加了其他功能，以及。 我很抱歉，如果我听起来像Incredibuild推销员 - 我只是一个非常满意的客户。
我已经连接使用Visual C ++之前大型应用类似的烦恼。 就我而言，我根本没有足够的可用内存和过度分页到磁盘被链接过程缓慢停了下来。 我加倍从1GB到2GB RAM取得了显着的改善。 您的开发盒多少运行？
我才发现，我们不得不通过事故中得到了包含在几乎每一个（静态）LIB头文件中定义字符串的大桌子。 （我说的是一个巨大的C ++项目。）当连接建立的EXE，它看起来像表的统一（只有一个单一的EXE结束了）或库的解析永远了。 把表在一个单独的C ++文件花了几个链接分钟的速度相对较慢的机器上。
不幸的是，我不知道如何找到这样的东西不是偶然的，其他。
对于调试版本，则可以使用增量链接，这样可以提高链路时间很多。
可悲的是有一定的缺陷，而VS2005将不会发出警告。
如果使用静态库，然后增量链接不会改变，如果对静态库文件中的部分工作。 解决的办法是设置连接选项“使用库的依赖输入”为“Yes”（这是一样的快速解决方案在VS2003构建）
如果使用附注注释-lib的，包括一个DLL的lib，并指定一个相对路径，而不是单独的lib，那么增量链接将停止工作。 解决的办法是单独指定lib和使用的链接器选项LIBPATH添加额外的LIB路径。
有些时候的.ilk文件将被损坏（增长超过200兆字节），然后突然增量链接直到走正常的时间的10倍以上。 有些时候，它会抱怨.ilk文件被损坏，但通常前几分钟后。 对我来说，解决办法是设置为“构建事件”下面的命令 - >“预链接事件”
在%% F（$（IntDir）*。之流）做（如果 “%%〜ZF” GTR “2亿”（德尔%% f）项）
60个库链接听起来像是一个公平一些。 这可能是一个有点极端措施，但它可能会从根本上加快速度。 创建一个新的解决方案，有几个项目，从现有的项目，这些添加的所有来源。 然后建立，而是将它们链接，并只保留小的测试。
获取具有多个处理器的计算机更快，使并行编译（这可能是默认的）。 要允许并行性的最大数量，请确保您的项目依赖关系是正确的，你没有不必要的依赖。
如果你是真正谈论的链接次，然后像东西快速的解决方案构建和Xoreax不会真的帮助不大（除了Incredilink，这可能）。 假设你是真正测量链路开始到结束链接，那么我建议你有库的数量问题。
链接阶段是，至少在最初，在IO装载了所有的对象和LIB文件的约束。 你可能会在你有60个库与一些大量的obj文件的主要项目一起的情况。 我怀疑你可能简单装载了所有这些库和.obj文件中会看到，至少部分，典型的Windows缓慢。
您可以轻松地进行测试。 采取所有这些LIB文件，并建立一个单一的库文件只是作为一个测试。 相反，与他们的60连接的，连接一个，看看你的时间的流逝。 这将是有趣的。
NTFS是notoriosly缓慢。 这shoudln't是7米与在Linux慢32秒时，但也可能是问题的一部分。 使用DLL的帮助，但你会吃亏的应用程序的启动时间，但不会是早期那样糟糕。 我相信，你不会有7米应用程序启动时间。
你可以尝试寻找这个： http://msdn.microsoft.com/en-us/library/9h3z1a69.aspx
基本上，你可以运行项目建立并联，如果你有多个内核。
在C ++中的建造时间减少步骤1是更多的内存。 从4GB切换到12GB后，我看到了我的链接的所有项目时跌落悬崖：从5:50到1:15。
我已经解决了我的链接问题，分享给大家。
我的项目的链接时间为7分钟，/增量：没有链接（链接时7分钟）。
用/增量，（联系时间7分钟，嵌入式清单时间7分钟）15分钟。 所以我关掉inremental。
我发现其他的依赖已经A.LIB，而忽略具体的图书馆有，太！
所以，我从忽略特定库打开/增量将其删除。 第一个链接时，需要5分钟，但表现内嵌时间都没有。
我不知道为什么，但增量链接工作过。
我回滚所有项目的代码，这样我就可以找到的lib的问题。 如果你做所有的上面，你可以试试我的方法。 祝好运！
