¿Por qué el enlace C++ no usa prácticamente ninguna CPU?

Question

En un proyecto nativo de C++, la vinculación en este momento puede tomar uno o dos minutos. Sin embargo, durante este tiempo, la CPU cae del 100% durante la compilación a prácticamente cero. ¿Significa esto que vincular es principalmente una actividad de disco?

Si es así, ¿es ésta la principal zona de un SSD haría grandes cambios? Pero, ¿por qué no se guardan todos mis archivos OBJ (o tantos como sea posible) en la memoria RAM después de la compilación para evitar esto? Con 4   GB de RAM, debería poder guardar un montón de acceso al disco y volver a conectarlo a la CPU, ¿no?

Actualización: por lo que es obvio es el seguimiento, puede el compilador y el enlazador charla VC++ mejor juntos para simplificar las cosas y mantener los archivos OBJ en la memoria, similar a cómo lo hace Delphi?

Answer 1

En las compilaciones de depuración en Visual Studio puede usar incremental linking, que le permite evitar mucho tiempo de enlace. Básicamente significa que, en lugar de vincular todo el archivo EXE (o DLL) desde cero, se basa en el que enlazó por última vez, reemplazando solo las cosas que cambiaron.

Sin embargo, esto no se recomienda para compilaciones de versiones liberadas, ya que agrega un poco de sobrecarga en tiempo de ejecución y puede dar como resultado un archivo EXE que es varias veces más grande que el habitual.

Answer 2

La vinculación es de hecho principalmente una actividad basada en disco. Borland Pascal (de vuelta en el día) mantendría todo el programa en la memoria, por lo que se vincularía tan rápido.

Sus archivos OBJ no se guardan en la RAM porque el compilador y el enlazador son programas separados. Si su entorno de desarrollo tenía un compilador y un enlazador integrados (en lugar de ejecutarlos como procesos separados), de hecho podría mantener todo en la memoria RAM.

Pero perdería la capacidad de separar el entorno de desarrollo de los compiladores y/o vinculadores; tendría que usar el mismo compilador/vinculador, y no podría ejecutar el compilador fuera del entorno.

Answer 3

Puede intentar instalar algunas de esas utilidades de discos RAM y mantener su directorio obj en el disco RAM o incluso en el directorio completo del proyecto. Eso debería acelerarlo considerablemente.

No se olvide de hacerlo permanente después :-D

Answer 4

Es difícil decir exactamente lo que está tomando el enlazador tanto tiempo sin saber cómo está interactuando con el sistema operativo. Afortunadamente, Microsoft proporciona Process Monitor para que pueda hacer precisamente eso.

Me ha ayudado a diagnosticar errores con el Visual Studio IDE y el depurador sin acceso a la fuente.

Answer 5

El Estudio Visual enlazador es en gran medida de E/S de la envolvente, pero ¿es así depende de algunas variables.

1. vinculación incremental (común en versiones de depuración) generalmente requiere mucho menos I/O.

2. Escribir un archivo PDB (para símbolos) puede consumir una gran cantidad de tiempo. Es un cuello de botella específico al que apunta Microsoft en 2010. La escritura PDB ahora se hace de forma asíncrona. No lo he intentado, pero he oído que puede ayudar a los tiempos de enlace bastante.

3. Si utiliza la generación de código de tiempo de enlace (LTCG) (común en versiones de versión), tiene inicialmente todas las E/S habituales. Luego, el enlazador vuelve a invocar el compilador para volver a generar el código de las secciones que se pueden optimizar aún más. Esta porción generalmente requiere mucho más CPU. De la mano, no sé si el enlazador realmente hace girar el compilador en un proceso separado y espera (en cuyo caso todavía verás un bajo uso de la CPU para el proceso del enlazador), o si la compilación se realiza en el proceso del enlazador (en cuyo caso verá que el enlazador atraviesa fases de E/S pesada y CPU pesada).

El uso de un SSD puede ayudar con las porciones de E/S encuadernadas. Simplemente tener un segundo disco puede ayudar, también. Por ejemplo, si su fuente y objetos están todos en una unidad, y usted escribe su PDB en una unidad separada, el enlazador debería pasar menos tiempo esperando la escritura PDB. Tener un segundo disco giratorio ha ayudado mucho a los tiempos de enlace de mi equipo actual.