为什么C++链接几乎不使用CPU？

Question

在本机C++项目中,现在链接可能需要一两分钟.然而,在此期间,CPU在编译期间从100%下降到几乎为零.这是否意味着链接主要是磁盘活动？

如果是这样,这是SSD会发生重大变化的主要领域吗？但是,为什么不是所有的OBJ文件(或尽可能多的)都在编译后保存在RAM中以避免这种情况？使用4 GB的RAM,我应该能够节省大量的磁盘访问并使其再次受CPU限制,不是吗？

更新:这样明显的随访,可在VC++编译器和链接在一起,更好地交谈,精简的东西,并保持OBJ文件在内存中,类似于如何德尔福不是吗？

Answer 1

链接确实主要是基于磁盘的活动.Borland Pascal(当天回来)会将整个程序保留在内存中,这就是它如此快速连接的原因.

您的OBJ文件不会保存在RAM中,因为编译器和链接器是单独的程序.如果您的开发环境具有集成的编译器和链接器(而不是将它们作为单独的进程运行),那么它确实可以将所有内容保存在RAM中.

但是你将失去将开发环境与编译器和/或链接器分开的能力 - 你必须使用相同的编译器/链接器,并且你将无法在环境之外运行编译器.

Answer 2

您可以尝试安装其中一些RAM磁盘实用程序,并将您的obj目录保存在RAM磁盘甚至整个项目目录中.这应该会大大加快速度.

不要忘记事后永久性:-D

Answer 3

在Visual Studio中的调试版本中,您可以使用增量链接,这通常可以避免花费大量时间进行链接.基本上它意味着它不是从头开始链接整个EXE(或DLL)文件,而是建立在你上次链接的文件之上,只替换改变的东西.

但是,这不建议用于发布版本,因为它会在运行时增加一些开销,并且可能导致EXE文件比平常大几倍.

Answer 4

Visual Studio链接器在很大程度上受I/O限制,但多少取决于一些变量.

1. 增量链接(在Debug版本中很常见)通常需要少得多的I/O.

2. 编写PDB文件(用于符号)可能会占用大量时间.这是微软在VS 2010中所针对的一个特定瓶颈.PDB写作现在是异步完成的.我没试过,但我听说它可以帮助链接时间相当多.

3. 如果您使用链接时代码生成(LTCG)(在发布版本中很常见),那么您最初拥有所有常用的I/O. 然后,链接器重新调用编译器以重新生成可以进一步优化的部分的代码.这部分通常占用大量CPU资源.另外,我不知道链接器是否实际在单独的进程中旋转编译器并等待(在这种情况下,您仍然会看到链接器进程的CPU使用率低),或者编译是否在链接器进程中完成(在这种情况下,您将看到链接器经历重I/O然后重CPU的阶段).

使用SSD可以帮助I/O绑定部分.只需拥有第二个驱动器也可以提供帮助.例如,如果你的源和目的都是一个驱动器上,而你写你的PDB到一个单独的驱动器,链接器应该花费更少的时间等待PDB作家.拥有第二个旋转驱动器帮助我当前团队的链接时间显着增加.