c# - rendimiento - Tiempos de compilación muy lento en Visual Studio 2005

visual studio code muy lento (30)

Tenemos casi 100 proyectos en una solución y un tiempo de compilación dev de solo segundos :)

Para construcciones de desarrollo local, creamos un Complemento de Visual Studio que cambia las Project references de DLL references y descarga los proyectos no deseados (y una opción para cambiarlos de curso).

Construye toda nuestra solución una vez
Descargue los proyectos en los que no estamos trabajando actualmente y cambie todas las referencias de proyectos a las referencias de DLL.
Antes del check-in, cambie todas las referencias de la DLL a las referencias del proyecto.

Nuestras construcciones ahora solo toman segundos cuando estamos trabajando solo en unos pocos proyectos a la vez. También podemos depurar los proyectos adicionales a medida que se vinculan a las DLL de depuración. Por lo general, la herramienta tarda de 10 a 30 segundos en realizar una gran cantidad de cambios, pero no es necesario que lo haga a menudo.

Actualización de mayo de 2015

El trato que hice (en los comentarios a continuación) fue que lanzaría el complemento a Open Source si recibe suficiente interés. 4 años más tarde tiene solo 44 votos (y Visual Studio ahora tiene dos versiones posteriores), por lo que actualmente es un proyecto de baja prioridad.

Estamos obteniendo tiempos de compilación muy lentos, que pueden llevar más de 20 minutos en dos núcleos de 2 GHz, máquinas 2G Ram.

Mucho de esto se debe al tamaño de nuestra solución, que ha crecido a más de 70 proyectos, así como a VSS, que es un cuello de botella en sí mismo cuando tienes muchos archivos. (El intercambio de VSS no es una opción desafortunadamente, así que no quiero que esto descienda a un VSS bash)

Estamos buscando fusionar proyectos. También buscamos tener múltiples soluciones para lograr una mayor separación de preocupaciones y tiempos de compilación más rápidos para cada elemento de la aplicación. Esto que puedo ver se convertirá en un infierno de DLL mientras tratamos de mantener las cosas sincronizadas.

Me interesa saber cómo otros equipos se han ocupado de este problema de escalado, ¿qué haces cuando tu base de códigos alcanza una masa crítica en la que estás perdiendo la mitad del día viendo cómo la barra de estado entrega mensajes de compilación?

ACTUALIZACIÓN Me olvidé de mencionar que esta es una solución de C #. Gracias por todas las sugerencias de C ++, pero han pasado unos años desde que tuve que preocuparme por los encabezados.

EDITAR:

Buenas sugerencias que han ayudado hasta ahora (sin decir que no hay otras sugerencias agradables a continuación, solo lo que ha ayudado)

Nueva computadora portátil de 3GHz: el poder de la utilización perdida funciona de maravilla cuando la administración
Deshabilitar Anti Virus durante la compilación
''Desconectar'' de VSS (en realidad la red) durante la compilación: puedo conseguir que eliminemos por completo la integración de VS-VSS y nos apeguemos a usar la interfaz de usuario de VSS

Todavía no resopla a través de una compilación, pero cada bit ayuda.

Orion mencionó en un comentario que los genéricos también pueden tener una jugada. Según mis pruebas, parece haber un rendimiento mínimo, pero no lo suficientemente alto como para estar seguro: los tiempos de compilación pueden ser inconsistentes debido a la actividad del disco. Debido a limitaciones de tiempo, mis pruebas no incluyeron tantos genéricos, o tantos códigos, como los que aparecerían en el sistema en vivo, por lo que pueden acumularse. No evitaría el uso de genéricos donde se supone que deben usarse, solo para el rendimiento en tiempo de compilación

SOLICITUD

Estamos probando la práctica de construir nuevas áreas de la aplicación en nuevas soluciones, importando en las últimas DLL según sea necesario, integrándolas en la solución más grande cuando estamos contentos con ellas.

También podemos hacer lo mismo con el código existente mediante la creación de soluciones temporales que solo encapsulan las áreas en las que necesitamos trabajar, y descartarlas después de reintegrar el código. Necesitamos sopesar el tiempo que llevará reinsertar este código en el tiempo que ganamos al no tener experiencias como Rip Van Winkle con recompilación rápida durante el desarrollo.

¿Qué tan grande es su directorio de compilación después de hacer una compilación completa? Si se queda con la configuración predeterminada, cada ensamblado que compile copiará todas las DLL de sus dependencias y las dependencias de sus dependencias, etc. a su directorio bin. En mi trabajo anterior cuando trabajaba con una solución de ~ 40 proyectos, mis colegas descubrieron que la parte más costosa del proceso de compilación era copiar estos ensambles una y otra vez, y que una compilación podría generar gigabytes de copias de los mismos archivos DLL y otra vez.

Aquí hay algunos consejos útiles de Patrick Smacchia, autor de NDepend, sobre lo que él cree que debería y no debería ser una asamblea separada:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

Básicamente hay dos formas de evitar esto, y ambas tienen inconvenientes. Una es reducir el número de ensamblajes, lo que obviamente es mucho trabajo. Otra es reestructurar sus directorios de compilación para que todas sus carpetas de bin estén consolidadas y los proyectos no copien las DLL de sus dependencias, no es necesario porque ya están todos en el mismo directorio. Esto reduce drásticamente la cantidad de archivos creados y copiados durante una compilación, pero puede ser difícil de configurar y puede dejarte con algunas dificultades para extraer únicamente las DLL requeridas por un ejecutable específico para el empaquetado.

Al elegir una CPU: el tamaño de la caché L1 parece tener un gran impacto en el tiempo de compilación. Además, generalmente es mejor tener 2 núcleos rápidos que 4 lentos. Visual Studio no utiliza los núcleos extra de manera muy efectiva. (Baso esto en mi experiencia con el compilador C ++, pero probablemente también sea cierto para C #).

Al mirar la máquina en la que está trabajando, ¿está configurada de manera óptima?

Acabamos de obtener nuestro tiempo de compilación para nuestro producto más grande de C ++ a escala empresarial de 19 horas a 16 minutos al asegurar que se instaló el controlador de filtro SATA correcto.

Sutil.

Algunas herramientas de análisis:

herramientas-> opciones-> configuración del proyecto VC ++ -> Tiempo de compilación = Sí le dirá el tiempo de compilación para cada vcproj.

Agregue /Bt cambie a la línea de comandos del compilador para ver cuánto tomó cada archivo CPP

Use /showIncludes para capturar /showIncludes anidadas (archivos de encabezado que incluyen otros archivos de encabezado), y vea qué archivos podrían guardar una gran cantidad de E / S mediante el uso de declaraciones avanzadas.

Esto lo ayudará a optimizar el rendimiento del compilador al eliminar las dependencias y los cerdos de rendimiento.

Antes de gastar dinero para invertir en discos duros más rápidos, intente construir su proyecto completamente en un disco RAM (suponiendo que tenga RAM libre). Puede encontrar varios controladores de disco RAM libres en la red. No encontrará ningún disco físico, incluidos SSD, que sea más rápido que un disco RAM.

En mi caso, un proyecto que tardó 5 minutos en construir en un i7 de 6 núcleos en una unidad SATA de 7200 RPM con Incredibuild se redujo en solo unos 15 segundos al usar un disco RAM. Teniendo en cuenta la necesidad de volver a copiar al almacenamiento permanente y la posibilidad de perder el trabajo, 15 segundos no es incentivo suficiente para usar un disco RAM y probablemente no haya mucho incentivo para gastar varios cientos de dólares en un disco de alta velocidad o disco SSD.

La pequeña ganancia puede indicar que la compilación estaba unida a la CPU o que el almacenamiento en caché de Windows fue bastante efectivo, pero como ambas pruebas se realizaron desde un estado en el que los archivos no estaban en caché, me inclino mucho hacia las compilaciones vinculadas a la CPU.

Dependiendo del código real que está compilando, su millaje puede variar, así que no dude en probarlo.

Asegúrese de que sus referencias sean referencias de Proyecto, y no directamente a las DLL en los directorios de salida de la biblioteca.

Además, configúrelos para que no se copien localmente, excepto cuando sea absolutamente necesario (el proyecto maestro EXE).

Buenas sugerencias que han ayudado hasta el momento (sin decir que no hay otras sugerencias agradables a continuación, si tiene problemas, le recomiendo leer entonces, simplemente lo que nos ha ayudado)

Nueva computadora portátil de 3GHz: el poder de la utilización perdida funciona de maravilla cuando la administración
Deshabilitar Anti Virus durante la compilación
''Desconectar'' de VSS (en realidad la red) durante la compilación: puedo conseguir que eliminemos por completo la integración de VS-VSS y nos apeguemos a usar la interfaz de usuario de VSS

Todavía no resopla a través de una compilación, pero cada bit ayuda.

También estamos probando la práctica de construir nuevas áreas de la aplicación en nuevas soluciones, importando en las últimas DLL según sea necesario, integrándolas en la solución más grande cuando estamos contentos con ellas.

Desactiva tu antivirus. Agrega edades al tiempo de compilación.

Desactive la integración de VSS. Puede que no tenga opción de usarlo, pero las DLL se renombran "accidentalmente" todo el tiempo ...

Y definitivamente verifique su configuración de encabezado precompilado. La guía de Bruce Dawson es un poco antigua, pero sigue siendo muy buena; échale un vistazo: http://www.cygnus-software.com/papers/precompiledheaders.html

Deshabilite la indexación del sistema de archivos en sus directorios de origen (específicamente los directorios obj si desea que su fuente se pueda buscar)

El equipo de Chromium.org enumeró varias opciones para acelerar la construcción (en este momento, aproximadamente a la mitad de la página):

En orden decreciente de aceleración:
Instale Microsoft hotfix 935225 .
Instale Microsoft hotfix 947315 .
Utilice un verdadero procesador multinúcleo (es decir, un Intel Core Duo 2, no un Pentium 4 HT).
Usa 3 construcciones paralelas. En Visual Studio 2005, encontrará la opción en Herramientas> Opciones ...> Proyectos y soluciones> Crear y ejecutar> número máximo de compilaciones de proyectos paralelas .
Deshabilite su software antivirus para archivos .ilk, .pdb, .cc, .h y solo compruebe si hay virus en modificar . Deshabilite escanear el directorio donde residen sus fuentes. No hagas nada estúpido.
Almacene y cree el código de Chromium en un segundo disco duro. En realidad, no acelerará la compilación, pero al menos su computadora seguirá siendo receptiva cuando realice la sincronización de gclient o una compilación.
Desfragmenta tu disco duro regularmente.
Deshabilitar la memoria virtual.

Es seguro que hay un problema con VS2008. Porque lo único que he hecho es instalar VS2008 para actualizar mi proyecto que se ha creado con VS2005. Solo tengo 2 proyectos en mi solución. No es grande Compilación con VS2005: 30 segundos Compilación con VS2008: 5 minutos

Hay algunas cosas que he encontrado útiles para el desarrollo de compilaciones de C # /.NET :

Combine proyectos pequeños en proyectos más grandes ya que hay una gran sobrecarga por proyecto en la construcción de una solución. (Use nDepender si es necesario para controlar las llamadas entre capas)
Haga que todos nuestros proyectos entren en el directorio de salida y luego configure "copiar local" en falso en todas las referencias del proyecto; esto puede generar una gran aceleración debido a la reducción de IO.
Apague su comprobador de virus para ver si hace mucha diferencia; en caso afirmativo, busque un comprobador de virus más rápido o excluya las carpetas "activas" de la herramienta de comprobación de virus
Utilice el monitor forzado y la herramienta interna sys para ver la forma en que sus compilaciones tardan tanto.
Considere un disco RAM para poner su directorio de salida.
Considera usar una SSD
Más memoria puede tener un gran efecto a veces - (reduzca el ariete en la máquina si obtiene una gran desaceleración quitando un pequeño ariete, puede obtener una gran velocidad agregando más) Elimine las referencias innecesarias del proyecto (puede que tenga que eliminar "usos" innecesarios primero)
Considere utilizar un marco de inyección de dependencias e interfaces para la capa de dominio más baja, por lo que solo es necesario volver a compilar todo cuando la interfaz cambia; es posible que esto no gane mucho dependiendo de la frecuencia con la que se cambie la interfaz.

Hay un conmutador MP no documentado en Visual Studio 2005, consulte http://lahsiv.net/blog/?p=40 , que permitiría la compilación paralela en base a archivos en lugar de a proyectos. Esto puede acelerar la compilación del último proyecto o, si compila un proyecto.

Instrucciones para reducir el tiempo de compilación de Visual Studio a unos pocos segundos

Desafortunadamente, Visual Studio no es lo suficientemente inteligente como para distinguir los cambios en la interfaz de un ensamblaje de los cambios en el cuerpo del código inconsecuente. Este hecho, cuando se combina con grandes soluciones entrelazadas, a veces puede crear una tormenta perfecta de "compilaciones completas" no deseadas casi cada vez que cambie una sola línea de código.

Una estrategia para superar esto es desactivar las compilaciones automáticas del árbol de referencia. Para ello, utilice el ''Administrador de configuración'' (Administrador de compilación / configuración ... luego en el menú desplegable Configuración activa de la solución, elija ''Nuevo'') para crear una nueva configuración de compilación llamada ''ManualCompile'' que copia desde la configuración de depuración, pero no marque la casilla ''Crear nuevas configuraciones de proyecto''. En esta nueva configuración de compilación, desmarque cada proyecto para que ninguno de ellos se genere automáticamente. Guarde esta configuración presionando ''Cerrar''. Esta nueva configuración de compilación se agrega a su archivo de solución.

Puede cambiar de una configuración de compilación a otra a través del menú desplegable de configuración de compilación en la parte superior de su pantalla IDE (la que generalmente muestra ''Depurar'' o ''Liberar''). Efectivamente, esta nueva configuración de compilación de ManualCompile dejará inútiles las opciones del menú Compilar para: ''Solución de compilación'' o ''Reconstruir solución''. Por lo tanto, cuando se encuentre en el modo ManualCompile, debe compilar manualmente cada proyecto que está modificando, lo que se puede hacer haciendo clic con el botón derecho en cada proyecto afectado en el Explorador de soluciones y seleccionando "Crear" o "Reconstruir". Debería ver que sus tiempos de compilación generales ahora serán de pocos segundos.

Para que esta estrategia funcione, es necesario que el VersionNumber que se encuentra en los archivos AssemblyInfo y GlobalAssemblyInfo permanezca estático en la máquina del desarrollador (no durante las versiones de lanzamiento, por supuesto) y que no firme sus archivos DLL.

Un posible riesgo de usar esta estrategia ManualCompile es que el desarrollador puede olvidarse de compilar los proyectos requeridos, y cuando inician el depurador, obtienen resultados inesperados (no pueden adjuntar depurador, archivos no encontrados, etc.). Para evitar esto, probablemente sea mejor usar la configuración de compilación ''Debug'' para compilar un esfuerzo de codificación más grande, y solo usar la configuración de compilación de ManualCompile durante las pruebas unitarias o para realizar cambios rápidos que sean de alcance limitado.

Noté que esta pregunta tiene siglos de antigüedad, pero el tema sigue siendo de interés hoy en día. El mismo problema me mordió últimamente, y las dos cosas que mejoraron más el rendimiento de compilación fueron (1) utilizar un disco dedicado (y rápido) para compilar y (2) usar la misma carpeta de salida para todos los proyectos y establecer CopyLocal en False en el proyecto referencias.

Algunos recursos adicionales:

Para compilaciones de C # .NET, puede usar .NET Demon . Es un producto que se hace cargo del proceso de creación de Visual Studio para hacerlo más rápido.

Lo hace analizando los cambios que ha realizado y crea solo el proyecto que realmente cambió, así como otros proyectos que realmente se basaron en los cambios que realizó. Eso significa que si solo cambia el código interno, solo necesita construir un proyecto.

Publiqué esta respuesta originalmente aquí: https://.com/questions/8440/visual-studio-optimizations#8473 Puedes encontrar muchos otros consejos útiles sobre esa página.

Si está usando Visual Studio 2008, puede compilar usando el indicador / MP para construir un único proyecto en paralelo. He leído que esta también es una característica no documentada en Visual Studio 2005, pero nunca la he probado.

Puede construir múltiples proyectos en paralelo usando el indicador / M, pero esto ya está configurado en la cantidad de núcleos disponibles en la máquina, aunque esto solo se aplica a VC ++, creo.

Si esto es C o C ++, y no estás usando encabezados precompilados, deberías.

Si se trata de un proyecto de C ++, entonces debería usar encabezados precompilados. Esto hace una gran diferencia en los tiempos de compilación. No estoy seguro de lo que cl.exe realmente está haciendo (sin usar encabezados precompilados), parece estar buscando muchos encabezados STL en todos los lugares incorrectos antes de ir finalmente a la ubicación correcta. Esto agrega segundos enteros a cada archivo .cpp único que se compila. No estoy seguro si esto es un error cl.exe, o algún tipo de problema STL en VS2008.

Si se trata de una aplicación web, configurar la creación por lotes en true puede ayudar según el escenario.

<compilation defaultLanguage="c#" debug="true" batch="true" >

Puede encontrar una descripción general aquí: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Tal vez tome algunas funciones comunes y cree algunas bibliotecas, de esa forma las mismas fuentes no se compilan una y otra vez para múltiples proyectos.

Si le preocupan las diferentes versiones de las DLL que se mezclan, use las bibliotecas estáticas.

También es posible que desee verificar referencias de proyectos circulares. Fue un problema para mí una vez.

Es decir:

Proyecto A hace referencia al Proyecto B

Proyecto B hace referencia al Proyecto C

Proyecto C hace referencia al Proyecto A

También estoy convencido de que hay un problema con VS2008. Lo estoy ejecutando en una computadora portátil Intel de doble núcleo con 3G Ram, con el antivirus apagado. La compilación de la solución suele ser bastante astuta, pero si he estado depurando una recompilación posterior a menudo se ralentizará hasta convertirse en un rastreo. De la luz de disco principal continua está claro que hay un cuello de botella de E / S del disco (también puede oírlo). Si cancelo la compilación y el apagado VS, la actividad del disco se detiene. Reinicie VS, vuelva a cargar la solución y luego reconstruya, y es mucho más rápido. Unitl la próxima vez

Mi opinión es que se trata de un problema de paginación de memoria: VS simplemente se queda sin memoria y el O / S inicia el intercambio de páginas para intentar generar espacio, pero VS exige mucho más que el intercambio de páginas, por lo que se ralentiza. No puedo pensar en otra explicación.

VS definitivamente no es una herramienta RAD, ¿verdad?

Tengo un proyecto que tiene 120 o más archivos, libs y dlls y me toma un tiempo considerable de compilación. Utilizo un árbol de archivos por lotes que llaman archivos make desde un archivo master batch. He tenido problemas con elementos extraños de encabezados incrementales (o era temperamental) en el pasado, así que los evito ahora. Hago una construcción completa con poca frecuencia, y generalmente la dejo hasta el final del día mientras salgo a caminar durante una hora (así que solo puedo adivinar que demora alrededor de media hora). Entonces entiendo por qué eso no es viable para trabajar y probar.

Para trabajar y probar, tengo otro conjunto de archivos por lotes para cada aplicación (o módulo o biblioteca) que también tienen todas las configuraciones de depuración en su lugar, pero aún así llaman a los mismos archivos make. Puedo activar o desactivar DEBUG de vez en cuando y también decidir sobre compilaciones o creaciones o si también quiero compilar libs de las que el módulo puede depender, y así sucesivamente.

El archivo por lotes también copia el resultado completado en la (o varias) carpetas de prueba. Dependiendo de la configuración, esto se completa en varios segundos a un minuto (en lugar de decir media hora).

Usé un IDE diferente (Zeus) ya que me gusta tener control sobre cosas como archivos .rc, y realmente prefiero compilar desde la línea de comandos, aunque estoy usando compiladores de MS.

Feliz de publicar un ejemplo de este archivo por lotes si alguien está interesado.

Tuve un problema similar en una solución con 21 proyectos y 1/2 millón de LOC. La mayor diferencia fue obtener discos duros más rápidos. Desde el monitor de rendimiento, la opción "Prom. Disk Queue ''saltaría significativamente en la computadora portátil indicando que el disco duro era el cuello de la botella.

Aquí hay algunos datos para los tiempos totales de reconstrucción ...

1) Ordenador portátil, Core 2 Duo 2GHz, 5400 RPM Drive (no estoy seguro de la caché. Fue Dell estándar inspiron).

Tiempo de reconstrucción = 112 segundos.

2) Escritorio (problema estándar), Core 2 Duo 2.3Ghz, solo 7200RPM Drive 8MB Cache.

Rebuild Time = 72 segundos.

3) Desktop Core 2 Duo 3Ghz, solo 10000 RPM WD Raptor

Rebuild Time = 39 segundos.

La unidad de 10,000 RPM no puede ser subestimada. Construye donde significativamente más rápido y todo lo demás, como mostrar la documentación, utilizando el explorador de archivos fue notable más rápido. Fue un gran aumento de la productividad al acelerar el ciclo de creación, desarrollo y código.

Teniendo en cuenta lo que las empresas gastan en los salarios de los desarrolladores, es una locura cuánto pueden desperdiciar, comprándoles las mismas PC que usa la recepcionista.

Tuvimos más de 80 proyectos en nuestra solución principal, que tardaron de 4 a 6 minutos en construirse, dependiendo de qué tipo de máquina estaba trabajando un desarrollador. Consideramos que es demasiado tiempo: por cada prueba, realmente se come sus FTE.

Entonces, ¿cómo obtener tiempos de construcción más rápidos? Como parece que ya sabes, es la cantidad de proyectos que realmente dañan el tiempo de construcción. Por supuesto, no queríamos deshacernos de todos nuestros proyectos y simplemente lanzar todos los archivos de origen en uno solo. Pero teníamos algunos proyectos que podíamos combinar sin embargo: como cada "proyecto de repositorio" en la solución tenía su propio proyecto de prueba individual, simplemente combinamos todos los proyectos de prueba en un solo proyecto de prueba global. Eso redujo el número de proyectos con aproximadamente 12 proyectos y de alguna manera se ahorró el 40% del tiempo para construir la solución completa.

Sin embargo, estamos pensando en otra solución.

¿También ha intentado configurar una nueva (segunda) solución con un nuevo proyecto? Esta segunda solución simplemente debe incorporar todos los archivos usando carpetas de solución. Porque es posible que se sorprenda al ver el tiempo de compilación de esa nueva solución con un solo proyecto.

Sin embargo, trabajar con dos soluciones diferentes tendrá una consideración cuidadosa. Los desarrolladores pueden estar inclinados a trabajar realmente en la segunda solución y descuidar por completo la primera. Como la primera solución con los más de 70 proyectos será la solución que se ocupa de su jerarquía de objetos, esta debería ser la solución donde su servidor de construcción debería ejecutar todos los tests de su unidad. Entonces, el servidor para Integración Continua debe ser el primer proyecto / solución. Tienes que mantener tu jerarquía de objetos, a la derecha.

La segunda solución con solo un proyecto (que se compilará mucho más rápido) será el proyecto donde las pruebas y la depuración serán realizadas por todos los desarrolladores. Sin embargo, ¡tienes que cuidarlos mirando el servidor de construcción! Si algo se rompe, DEBE arreglarse.

Una alternativa más barata a Xoreax IB es el uso de lo que llamo compilaciones de archivos uber. Básicamente es un archivo .cpp que tiene

#include "file1.cpp" #include "file2.cpp" .... #include "fileN.cpp"

Luego compila las unidades uber en lugar de los módulos individuales. Hemos visto tiempos de compilación desde 10-15 minutos hasta 1-2 minutos. Es posible que tenga que experimentar cuántos #includes por archivo uber tienen sentido. Depende de los proyectos. etc. Quizás incluyas 10 archivos, tal vez 20.

Usted paga un costo así que tenga cuidado:

No puede hacer clic con el botón derecho en un archivo y decir "compilar ..." ya que debe excluir los archivos cpp individuales de la compilación e incluir solo los archivos cpp de uber
Debe tener cuidado con los conflictos de variables globales estáticas.
Cuando agrega módulos nuevos, debe mantener los archivos actualizados al día

Es un poco doloroso, pero para un proyecto que es en gran medida estático en términos de nuevos módulos, el dolor inicial podría valer la pena. He visto este método vencer a IB en algunos casos.

Use la compilación distribuida. Xoreax IncrediBuild puede reducir el tiempo de compilación a pocos minutos.

Lo he usado en una gran solución C / C ++ que generalmente tarda de 5 a 6 horas en compilarse. IncrediBuild ayudó a reducir este tiempo a 15 minutos.