studio - visual c++ descargar

¿Cómo mejorar los tiempos de compilación de Visual C++?

Question

Estoy compilando 2 proyectos de C ++ en un buildbot, en cada commit. Ambos son alrededor de 1000 archivos, uno es 100 kloc, el otro 170 kloc. Los tiempos de compilación son muy diferentes de gcc (4.4) a Visual C ++ (2008).

Las compilaciones de Visual C ++ para un proyecto abarcan los 20 minutos. No pueden aprovechar los múltiples núcleos porque un proyecto depende del otro. Al final, una compilación completa de ambos proyectos en Debug and Release, en 32 y 64 bits toma más de 2 1/2 horas.

Las compilaciones de gcc para un proyecto toman en los 4 minutos. Se puede paralelizar en los 4 núcleos y toma alrededor de 1 minuto y 10 segundos. Las 8 compilaciones para 4 versiones (Debug / Release, 32/64 bits) de los 2 proyectos se compilan en menos de 10 minutos.

¿Qué está pasando con los tiempos de compilación de Visual C ++? Básicamente son 5 veces más lentos.

¿Cuál es el tiempo promedio que se puede esperar para compilar un Kloc C ++? Los míos son 7 s / kloc con vc ++ y 1.4 s / kloc con gcc.

¿Se puede hacer algo para acelerar los tiempos de compilación en Visual C ++?

Answer 1

¿Cómo estás construyendo los proyectos de Visual Studio? ¿Estás ejecutando el ide (devenv) con el proyecto y /build o tienes un archivo MAKE similar a lo que supongo que estás usando para gcc? Supongo que ambas compilaciones utilizan un archivo MAKE similar, pero pensé que valía la pena verificarlo.

¿Estás usando encabezados precompilados para cualquiera de los compiladores? Si NO está usando encabezados precompilados para VS, entonces le gustaría cambiar a usarlos. Personalmente, recomendaría utilizar el enfoque #pragma hdrstop lugar de un único archivo de cabecera todo incluido, pero si actualmente NO está utilizando encabezados precompilados y desea probarlo, un solo archivo de encabezado todo incluido que se incluye forzosamente (con el /FI compilador de línea de comando del compilador) se puede probar rápidamente sin ningún cambio de código.

Escribí sobre /FI y #pragma hdrstop aquí: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html

Answer 2

¿Estás construyendo en la misma máquina? ¿Estás usando el mismo sistema operativo? He visto diferencias de velocidad en la región de 3-10x al comparar GCC en Cygwin y GCC en una máquina VirtualBox que se ejecuta dentro del alojamiento de Windows Cygwin.

Answer 3

El libro "Diseño de software C ++ a gran escala" de John Lakos contiene muchos consejos para estructurar su código y diseño para proyectos a gran escala. Incluye muchos consejos para acelerar la compilación. No está directamente relacionado con Visual C ++, pero vale la pena leerlo de todos modos.

Answer 4

En primer lugar, en la mayoría de los casos puede crear configuraciones de depuración y liberación del mismo proyecto en paralelo.

Además, lo que describes suena terriblemente lento: parece que no usas encabezados precompilados en VC ++ o los usas de forma incorrecta: están específicamente destinados a mejorar el tiempo de compilación.

Answer 5

He escrito dos artículos sobre técnicas que reducen el tiempo de compilación. Entre estas técnicas, se incluye una publicación sobre encabezados precompilados y compilaciones de unidades que pueden ayudarlo a mejorar los tiempos de compilación. Incluyen scripts de CMake que manejan las técnicas de forma transparente.

Answer 6

Los proyectos que dependen uno del otro no implican que no sea posible la paralelización. Los sistemas de compilación son lo suficientemente inteligentes como para descubrir y evitar dependencias críticas. De lo contrario, gcc no podría usar 4 núcleos.

Entonces (además de otros pasos), ¿por qué no intentas habilitar el multiproceso en Visual Studio usando / MP (ver http://msdn.microsoft.com/en-us/library/bb385193.aspx ).

Answer 7

No es la respuesta directa para la pregunta, pero en mi empresa estamos utilizando IncrediBuild para la compilación distribuida. Realmente acelera el proceso de compilación. http://incredibuild.com/visual_studio.htm

Answer 8

No sé si esto todavía es un problema y la mejora que obtuviste en la hora de la menta, pero si aún se mantiene, msbuild no sabe cómo orquestar simultáneamente en un proyecto (cada cpp debe ser compilable por separado a menos que tengas algunos codegens - los codegenes se mueven mejor a un proyecto separado) hay que descargar el kit de desarrollo del controlador o .NET SSCLI ya que ambos tienen nmake, build, que se sabe que paralelizan bien las cosas. SSCLI ya tenía la configuración de compilación, no recuerde si DDK tiene algunas muestras de compilación de lo que tiene que comenzar desde el principio.

Además, un artículo algo antiguo sobre la paralelización de MSBuild no entra en detalles, pero menciona algunas diferencias entre msbuild y msbuild + sln reales. Si el / MP vs. / Gm fue el único problema, entonces puede que tenga que hacer un pequeño script o C # exe para editar los archivos .proj para la creación del laboratorio. O utilice la anulación explícita de línea cmd en proyectos y tome esa opción de una env var.

Answer 9

Parece muy extraño que haya tanta diferencia ... ¡pero no hay ninguna razón para que no puedas aprovechar las multinúcleas en Visual tampoco!

Básicamente tienes 4 modos de compilación: (Debug / Release) x (32bits / 64bits), cada uno es totalmente independiente del otro, puedes ejecutar perfectamente el 4 en paralelo, aprovechando al máximo los 4 núcleos disponibles. O simplemente pruebe el enfoque MultiProcessor en Visual Studio también.

Sin embargo, eso no va a cortarlo. 150 minutos contra 10 minutos es una gran brecha. Desde mi experiencia personal, hay 2 factores principales para reducir el tiempo de compilación:

• tener todos los archivos usados ​​en un disco local (usando la replicación de los remotos si es necesario) y todos los archivos creados localmente también (.o .so)
• utilice todos los núcleos a su disposición, y si puede, incluso vaya a Multi Machines (distcc, etc.)

Answer 10

Tal vez haya un problema con la comprobación de dependencia, a menos que esté forzando una reconstrucción completa.

Podría hacer algunas bibliotecas estáticas. Ponga el código que rara vez cambia en las bibliotecas.

Las partes más lentas de construir un programa:

1. Apertura y cierre de archivos.
2. Analizando y traduciendo archivos fuente.

En general, las fases de creación de enlaces y ejecutables son las más rápidas.

Has decidido:

1. ¿Qué fases son las más lentas?
2. ¿Qué archivos son más lentos para compilar?

Recuerde, al determinar la eficiencia, siempre perfile (de una manera u otra).

Answer 11

Compile y vincule un archivo cpp a la vez , incluso cuando los cambios del archivo de encabezado afecten a varios archivos cpp. Esto se puede lograr con Visual Studio Macro:

Dim WithEvents myTimer As Timers.Timer

Sub CompileAndLinkCurrentCppFile()
    DTE.ExecuteCommand("Build.Compile")
    myTimer = New Timers.Timer
    myTimer.Interval = 0.05
    myTimer.Start()
End Sub

Sub myTimer_Elapsed(ByVal ee As Object, ByVal dd As Timers.ElapsedEventArgs) Handles myTimer.Elapsed
    If DTE.Solution.SolutionBuild.BuildState <> vsBuildState.vsBuildStateInProgress And DTE.Solution.SolutionBuild.LastBuildInfo <> 1 Then
        myTimer.Stop()
        DTE.ExecuteCommand("Build.Link")
    End If
End Sub

Answer 12

Una cosa que ralentiza el compilador de VC ++ es si tiene un archivo de encabezado que inicializa instancias concretas de tipos de valores de const no trival. Puede ver que esto suceda con las constantes de tipo std::string o GUID. Afecta tanto a la compilación como al tiempo de enlace.

Para un dll único, esto causó una ralentización de 10x. Ayuda si los coloca en un archivo de encabezado precompilado, o simplemente los declara en un encabezado y los inicializa en un archivo cpp.

Eche un vistazo al escáner de virus y asegúrese de experimentar con los encabezados precompilados, sin él no verá lo mejor de VC ++.

Ah, sí, y asegúrese de que la carpeta% TMP% esté en la misma partición donde se escribe su compilación, ya que VC ++ crea archivos temporales y los mueve más adelante.