[c#] Tiempos de compilación muy lento en Visual Studio 2005


14 Answers

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.

Question

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.




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.




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.




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.




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.




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




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.




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.




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 #).







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:

  1. 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
  2. Debe tener cuidado con los conflictos de variables globales estáticas.
  3. 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.




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.




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




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).




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:




Related