¿Qué es el cuello de botella de rendimiento de compilación de C++?

Question

Cuando realizo una nueva compilación para mi proyecto, que incluye más de 10 librerías de código abierto. Tarda unos 40 minutos. (en hardware normal)

Pregunta: ¿dónde están realmente mis cuellos de botella? disco duro buscando o CPU Ghz? No creo que multi-core ayudaría mucho a corregir?

--Editar 1--
mi normal de hardware = i3 OC a 4.0GHz, 8GB 1600MHz DDR3 y un 2 TB Western Digital

--Editar 2--
mi código = 10%, libs = 90%, sé que no tengo que construir todo cada vez, pero me gustaría saber cómo mejorar el rendimiento de la compilación, así que al comprar una nueva PC para el desarrollador, tomaría una decisión más inteligente.

--Editar 3--
cc = Visual Studio (maldito)

Answer 1

Desde VS 2010, VS puede usar varios núcleos cuando compila un solo proyecto. También puede compilar múltiples proyectos en paralelo. Sin embargo, la aceleración paralela no parece ser significativa en mi experiencia: p. Xcode es mucho mejor haciendo compilaciones paralelas.

Afortunadamente, no es necesario reconstruir las bibliotecas de código abierto cada vez, ¿verdad? Puede construirlos una vez, almacenar los archivos .lib en control de versiones y usarlos para compilaciones posteriores.

¿Has probado los archivos de encabezado precompilados para tu propio código? Esto puede producir una aceleración masiva.

Answer 2

Estás equivocado, multi-núcleo trae una tremenda aceleración, justo hasta el momento en su disco duro se da por vencido en realidad :)

Prueba por ejemplo: distcc, que trae compilaciones distribuidas (Mi compilación utiliza aproximadamente 20 núcleos en paralelo, en realidad está vinculado por la fase de preprocesamiento local).

En cuanto al cuello de botella real, tiene algo que ver con el mecanismo #include. Los lenguajes con módulos se compilan mucho más rápido ...

Answer 3

Cuando compila desde cero, sí, llevará más tiempo. Utilice la tecnología make de 40 años, que VS incluye como gestión de proyectos, para compilar solo lo que debe compilarse después de la primera ejecución.

Dicho esto, el modelo de unidad de traducción de C++ más el uso extensivo de plantillas puede ser un problema práctico significativo.

Answer 4

compilación multinúcleo ayuda, tremendamente en la mayoría de los casos.

tendrá que analizar sus proyectos, y el tiempo invertido en cada fase para determinar dónde están los cuellos de botella.

En proyectos típicos grandes de C++, el proceso suele ser unida a la CPU y luego a un disco. si es al revés, probablemente estés en el infierno de dependencia del encabezado.

En realidad, hay un montón de maneras de reducir los tiempos de compilación y la dependencia en sus proyectos.la mejor referencia singular que conozco es por Lakos:

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_1?ie=UTF8&qid=1296569079&sr=8-1

que es una de las prácticas más importantes libros/C++ que he leído.

normalmente puede reducir los tiempos de compilación de forma espectacular (por ejemplo, más de 40 veces más rápido si se lo toma muy en serio), pero puede tomar mucho tiempo y trabajo corregir las bases de código existentes.

Answer 5

40 minutos para construir es más probable (De hecho, a los 40 minutos llegaría a decir casi definitivamente) causado por el uso de #include. Está incluyendo cosas que no necesitan ser incluidas, es posible que solo necesiten enviar declaraciones.

Ordenar su código hará GRANDES diferencias. Sé que es mucho trabajo, pero te sorprenderás. En una compañía que trabajé en una biblioteca que demoró más de 30 minutos en construir se optimizó hasta una construcción de 3 minutos en poco más de una semana, asegurándome de que se necesitaban todos los #includes y agregando declaraciones avanzadas en lugar de #includeing. Esta biblioteca tenía significativamente más de un millón de líneas de código para hacerte una idea ...