resuelve - ¿Cómo debo detectar el cuello de botella del tiempo de compilación en un proyecto grande de C++?

practica cuello de botella

Question

Quiero reducir el tiempo de compilación de un gran proyecto de C ++. Intenté usar encabezados, interfaces, etc. precompilados. Pero antes de continuar, quiero saber si alguna herramienta que ayude a detectar por qué el tiempo de compilación es tan largo. Alguien sugiere pc-lint y yo daré una oportunidad. ¿Cómo debo detectar archivos #include innecesarios en un proyecto grande de C ++? Pero si hay otras herramientas que analizan el tiempo de compilación y hablan de sugerencias para aumentar la velocidad de compilación, avísenme. Gracias por adelantado.

Entorno: Microsoft Visual Studio C ++ 2008 o 2010.

Answer 1

C ++ no es modular (todavía), los cuellos de botella de compilación a menudo deben incluir problemas; es decir, usar demasiados archivos cuando no son necesarios. También es posible que esos complementos sean necesarios en este momento , pero podrían volverse superfluos con una simple reingeniería.

• para detectar las aplicaciones superfluas, puedes verificar la include-what-you-use , el único problema que tendrás es que funciona en la parte superior de Clang, por lo que necesitarás algo de configuración allí.
• de lo contrario, necesita revisar su código, y específicamente los encabezados .

Como la herramienta es autosuficiente y está documentada, permítame ampliar un poco el proceso de revisión.

1. Cualquier encabezado que tenga más de un par #include es altamente sospechoso.
2. Por el contrario, si tiene un archivo de origen repleto de varios tipos y funciones y solo incluye un par, probablemente signifique que uno de los encabezados trae demasiado.

Si tiene problemas para saber qué se necesita, qué no, y cómo eliminar encabezados superfluos, le recomiendo una lectura de Pimpls - Marcas de belleza en las que puede confiar ; Si no sabe qué es un Pimpl, lea Cortafuegos de compilación . Sin embargo, aconsejaría cautela, Pimpl tiene un tiempo de ejecución y un costo de mantenimiento, así que solo úselo cuando sea realmente necesario. Personalmente, lo recomendaría absolutamente en los encabezados públicos de una biblioteca que entregue a terceros (compatibilidad ABI) y, de lo contrario, trataré de evitarlo.

Si la inspección manual no es su fuerte, puede generar la salida del preprocesador para cada encabezado (no se preocupe demasiado por los archivos de origen) y verifique las salidas más grandes.

Answer 2

No conozco ninguna herramienta para mejorar el tiempo de compilación, pero puedo recomendar algunos remedios manuales (considere esto como un comentario):

1. Haga que #include guardias con cada archivo de encabezado, para que las inclusiones múltiples no produzcan ningún problema
2. Reduzca el cuerpo de la función miembro, el cuerpo de la función en línea se coloca directamente en los archivos de encabezado; solo tienen sus declaraciones
3. Compruebe si no hay funciones de template y clases innecesarias; recuerda que los tempaltes se vuelven en inline por defecto. Demasiado de plantillas / metaprogramas causa un gran tiempo de compilación.
4. Si el número de #define s fuera innecesariamente alto, entonces aumentaría la etapa de preproceso, lo que en última instancia aumenta el tiempo de compilación

Answer 3

Usted podría mirar en las unidades de unidad.
Básicamente, incluye todos los archivos .cpp en un archivo .cpp y solo compila ese archivo. Lo he probado en un gran proyecto y fue realmente efectivo.
Funciona debido a que usa mucho menos E / S cuando incluye todos sus encabezados / cpp una vez y no para cada cpp.

Ahora ya no usamos las unidades de construcción porque todos obtuvimos una actualización de hardware de SSD, y son simplemente increíbles.

Aquí hay una pregunta SO relacionada con las compilaciones de Unity: # ¿incluir todos los archivos .cpp en una sola unidad de compilación?

Answer 4

Un enfoque que me gusta es revisar la salida del preprocesador de algunas de sus fuentes: solo lea un poco desde la perspectiva del compilador en lugar de la representación un tanto abstracta que es #inclu . lo más probable es que encuentre algunos fragmentos grandes de inclusión / bibliotecas que no necesita y no era necesariamente consciente de la existencia (o necesidad) de la dependencia / inclusión. A partir de ahí, decide qué dependencias se pueden eliminar. incluso si sus dependencias fueran todas correctas, los resultados grandes también pueden sugerir cómo podría abordar la división de módulos más grandes en partes más pequeñas.