在本机C ++项目中，现在链接可能需要一两分钟。然而，在此期间，CPU在编译期间从100％下降到几乎为零。这是否意味着链接主要是磁盘活动？
如果是这样，这是SSD会发生重大变化的主要领域吗？但是，为什么不是所有的OBJ文件（或尽可能多的）都在编译后保存在RAM中以避免这种情况？使用4 GB的RAM，我应该能够节省大量的磁盘访问权限并使其再次受CPU限制，不是吗？
更新：所以显而易见的后续工作是，可以 VC ++编译器和链接器更好地协同工作以简化事物并将OBJ文件保存在内存中，类似于{ {3}}做到了吗？
答案 0 :(得分：14)
链接确实主要是基于磁盘的活动。 Borland Pascal（当天回来）将把整个程序保存在内存中，这就是它如此快速连接的原因。
您的OBJ文件未保存在RAM中，因为编译器和链接器是单独的程序。如果您的开发环境具有集成的编译器和链接器（而不是将它们作为单独的进程运行），那么它确实可以将所有内容保存在RAM中。
但是你将失去将开发环境与编译器和/或链接器分开的能力 - 你必须使用相同的编译器/链接器，并且你将无法在环境之外运行编译器。
答案 1 :(得分：7)
您可以尝试安装其中一些RAM磁盘实用程序，并将您的obj目录保存在RAM磁盘甚至整个项目目录中。这应该会加速它。
不要忘记事后将其永久化:-D
答案 2 :(得分：6)
在Visual Studio中的调试版本中，您可以使用incremental linking，这通常可以避免花费大量时间进行链接。基本上它意味着它不是从头开始链接整个EXE（或DLL）文件，而是建立在你上次链接的文件之上，只替换那些改变的东西。
然而，这不建议用于发布版本，因为它会在运行时增加一些开销，并且可能导致EXE文件比平常大几倍。
答案 3 :(得分：6)
Visual Studio链接器在很大程度上受I / O限制，但多少取决于一些变量。
增量链接（在Debug版本中很常见）通常需要少得多的I / O.
编写PDB文件（用于符号）可能会占用大量时间。这是微软在VS 2010中所针对的一个特定瓶颈.PDB写作现在是异步完成的。我没有尝试过，但我听说它可以帮助链接时间相当多。
如果您使用链接时代码生成（LTCG）（在发布版本中很常见），那么您最初拥有所有常用的I / O.然后，链接器重新调用编译器以重新生成可以进一步优化的部分的代码。这部分通常占用大量CPU资源。另外，我不知道链接器是否实际在单独的进程中旋转编译器并等待（在这种情况下，您仍然会看到链接器进程的CPU使用率低），或者编译是否在链接器进程中完成（在这种情况下，你会看到链接器经历了重I / O然后重CPU的阶段。）
使用SSD可以帮助处理I / O边界部分。只需拥有第二个驱动器也可以提供帮助。例如，如果源和对象都在一个驱动器上，并且您将PDB写入单独的驱动器，则链接器应该花费更少的时间等待PDB编写器。进行第二次旋转驱动有助于我当前团队的链接时间显着。
答案 4 :(得分：3)
很难说在不知道如何与操作系统交互的情况下，链接器到底需要多长时间。值得庆幸的是，Microsoft提供了Process Monitor，因此您可以做到这一点。
这有助于我使用Visual Studio IDE和调试器诊断错误而无法访问源代码。