为什么C ++链接几乎不使用CPU？
在本地C ++项目上，现在链接可能需要一两分钟。 然而，在此期间，CPU在编译期间从100％下降到几乎为零。 这是否意味着链接主要是磁盘活动？
如果是这样，这是SSD将发生重大变化的主要领域吗？ 但是，编译完成后，为什么不把所有OBJ文件（或尽可能多）保存在RAM中以避免这种情况？ 有了4 GB的RAM，我应该可以节省大量的磁盘访问，并再次进行CPU限制，不是吗？
更新：所以显而易见的后续行动是，VC ++编译器和链接器可以更好地对话以更好地简化事物并将OBJ文件保存在内存中，类似于Delphi如何执行它？
链接确实主要是基于磁盘的活动。 Borland Pascal（当天早些时候）会将整个程序保存在内存中，这就是为什么它会如此快速地连接。
您的OBJ文件不保存在RAM中，因为编译器和链接器是独立的程序。 如果您的开发环境具有集成的编译器和链接器（而不是将它们作为单独的进程运行），它确实可以将所有内容都保存在RAM中。
但是您将失去将开发环境与编译器和/或链接器分离的能力 - 您将不得不使用相同的编译器/链接器，并且无法在环境外运行编译器。
您可以尝试安装一些RAM磁盘实用程序，并将您的obj目录保存在RAM磁盘或整个项目目录中。 这应该大大加快它的速度。
不要忘记在事后永久保存:-D
Visual Studio链接器在很大程度上是I / O绑定的，但多少取决于几个变量。
增量链接（在Debug版本中很常见）通常需要更少的I / O。
编写一个PDB文件（用于符号）会消耗大量时间。 这是微软在VS 2010中的一个特定瓶颈。PDB写作现在是异步完成的。 我没有尝试过，但我听说它可以帮助链接时间相当多。
如果您使用链接时代码生成（LTCG）（在发行版本中很常见），那么您最初拥有所有通常的I / O。 然后，链接器重新调用编译器为可以进一步优化的部分重新生成代码。 这部分通常要占用大量CPU资源。 我不知道链接器是否真的在单独的进程中编译了编译器并等待（在这种情况下，链接器进程的CPU使用率仍然很低），或者编译是在链接器进程中完成的（在这种情况下，你会看到链接器经历了重I / O，然后是重CPU的阶段）。
使用SSD可以帮助I / O绑定部分。 简单地拥有第二个驱动器也可以提供帮助。 例如，如果源代码和对象全部位于一个驱动器上，并且将PDB写入单独的驱动器，则链接器应该花更少的时间等待PDB编写器。 第二次旋转驱动帮助我当前团队的连接时间显着。
链接地址: http://www.djcxy.com/p/85459.html