Las compilaciones de depuración se compilan mucho más despacio que la versión

Question

En Visual Studio 2005 tenemos una única biblioteca con 195 archivos cpp que tarda unos 2 minutos en compilarse para el lanzamiento pero aproximadamente 6 minutos en compilarse para la depuración.

Siempre pensé que las versiones de lanzamiento deberían demorar más debido a la optimización. ¿Por qué una compilación de depuración tarda mucho más tiempo que la versión? ¿Hay alguna forma de acelerar nuestra compilación de depuración para que sea tan rápida como la versión?

Tenemos una buena cantidad de código boost/stl.

Answer 1

Voy a poner el comentario de starbolin aquí como la respuesta: manzanas y naranjas. Las conjeturas de Charley de I/O Limited no parecían tener éxito con mi cálculo de Process Monitor de 600 MB escrito para depuración y 300 MB para la versión. Es decir, escribir 300 MB adicionales tomaría unos segundos, no 4 minutos.Por lo tanto, llegué a la conclusión de que es probable que haya un montón de cosas diferentes entre versiones de Debug y Release. Aunque la optimización debería llevar más tiempo que ninguna optimización, estas otras actividades solo de depuración deben tomar más tiempo que eso. Sería bueno ver un desglose de exactamente dónde va el tiempo para Debug and Release, pero parece claro que son procesos bastante diferentes y Debug solo lleva mucho más tiempo, al menos para Visual Studio 2005 y el proyecto que comparaté.

Answer 2

Mejor estimación: las compilaciones de depuración están limitadas por E/S, mientras que las compilaciones de versión son limitadas por el procesador (en este caso).

Hemos realizado una amplia evaluación comparativa de nuestro sistema de compilación: muchos proyectos grandes, algunos pequeños. Las compilaciones DEBUG escriben mucha información *.pdb, archivos *.obj mucho más grandes (para la información de depuración adicional), etc. El resultado es una actividad de disco enormemente mayor. Esto se acentúa aún más si usted tiene un montón de "literales" en su código fuente (tablas, símbolos, cadena de literales), etc.

Por el contrario, la RELEASE construye escribir a cabo mucho más pequeña *.obj archivos, y doesn No se moleste en escribir las bases de datos de "depuración" (si compila RELEASE con los interruptores típicos). Sin embargo, el enlazador en las compilaciones RELEASE tiene que hacer sus optimizaciones y otro trabajo mucho más significativo que simplemente no se hace en DEBUG, por lo que está vinculado al procesador. Esto se penaliza en el tiempo adicional por RELEASE si "compila para maximizar la velocidad/tamaño" con los modificadores más desafiantes para el enlazador.

(Sin embargo, sí, el RELEASE construcción aún debe de E/S de actualización de las direcciones en el bienestar ejecutable incorporado-en-disco, pero ya que el ejecutable es mucho más pequeño en el RELEASE compilación, página mucho menos, por lo que la pena de E/S en RELEASE construcción no es tanto como para DEBUG acumulación.)

que está observando un 3x "RELEASE es más caro que DEBUG". Eso es correcto para algunos proyectos que están vinculados a E/S con muchas plantillas, muchos símbolos y literales, etc. Verifique sus discos: ¿están llenos, o simplemente "lentos", y/o con algunos sectores defectuosos? ? Esos empeorarán (serán más lentos) las compilaciones DEBUG.

Sí, otras construcciones deben ser al revés, con "RELEASE algo así como 3 veces más caro que DEBUG". Esas compilaciones están vinculadas con el procesador/vinculador, en lugar de estar vinculadas a E/S.

[ACTUALIZACIÓN], veo en el comentario sobre la pregunta que esto es para "static-library, no-linking". Es un escenario bastante, en el peor de los casos, para una penalización de tiempo para I/O (mucha actividad de disco, sin enlaces) y sin una penalización de procesador (ya que no se realizan optimizaciones). Por lo tanto, si tiene un 3x "DEBUG -es más lento-que-RELEASE", probablemente sea tan malo como se pueda (para este proyecto), y eso no es atípico. Cuando agrega opciones de enlace, el RELEASE se volverá más lento.