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

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

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

Nuestras compilaciones ahora solo toman segundos cuando estamos trabajando en unos pocos proyectos a la vez. También podemos depurar los proyectos adicionales, ya que se vincula a las DLL de depuración. La herramienta tarda típicamente 10-30 segundos para hacer un gran número de cambios, pero usted no tiene que hacerlo tan a menudo.

Actualización de mayo de 2015

El trato que hice (en los comentarios a continuación), fue que liberaría el plugin a Código Abierto si obtiene suficiente interés. 4 años después solo tiene 44 votos (y Visual Studio ahora tiene dos versiones posteriores), por lo que actualmente es un proyecto de baja prioridad.

Tuve un problema similar en una solución con 21 proyectos y 1/2 millón de LOC. La mayor diferencia fue conseguir discos duros más rápidos. Desde el monitor de rendimiento el ' Avg. 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) Laptop, Core 2 Duo 2GHz, Unidad de 5400 RPM (no estoy seguro de la caché. Era estándar Dell inspiron).

Tiempo de reconstrucción = 112 segundos.

2) Escritorio (problema estándar), Core 2 Duo 2.3 Ghz, caché de 8 MB de una sola unidad de 7200 RPM.

Tiempo de reconstrucción = 72 segundos.

3) Desktop Core 2 Duo 3GHz, single 10000 RPM WD Raptor

Tiempo de reconstrucción = 39 segundos.

La unidad de 10.000 RPM no se puede subestimar. Compilaciones donde significativamente más rápido además de todo lo demás como la visualización de documentación, el uso del explorador de archivos fue notablemente más rápido. Fue un gran impulso de productividad al acelerar el ciclo de compilación y ejecución de código.

Dado lo las empresas gastan en salarios de desarrolladores es una locura cuánto pueden desperdiciar comprar equiparlos con los mismos PC que usa la recepcionista.

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

Lo hace analizando los cambios que realizó, y construye solo el proyecto que realmente cambió, así como otros proyectos que realmente dependieron de los cambios que realizó. Eso significa que si solo cambia el código interno, solo necesita compilar un proyecto.

Apague su antivirus. Añade edades al tiempo de compilación.

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

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

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

Visual Studio desafortunadamente no es lo suficientemente inteligente como para distinguir los cambios en la interfaz de un ensamblado de los cambios intrascendentes en el cuerpo del código. 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 cambia una sola línea de código.

Una estrategia para superar esto es deshabilitar las compilaciones automáticas del árbol de referencia. A haga esto, use el 'Configuration Manager' (Build / Configuration Manager...luego, en el menú desplegable Configuración de la solución activa, elija 'Nuevo') para crear una nueva configuración de compilación llamada 'ManualCompile' que copie desde la configuración de depuración, pero no marque la casilla de verificación 'Crear nuevas configuraciones de proyecto'. En esta nueva configuración de compilación, desmarque cada proyecto para que ninguno de ellos se compile automáticamente. Guarde esta configuración pulsando 'Cerrar'. Esta nueva configuración de compilación se añade 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 la pantalla de su IDE (la que generalmente muestra 'Debug' o 'Release'). Efectivamente, este nuevo ManualCompile build configuration hará inútiles las opciones del menú Build para: 'Build Solution 'o'Rebuild Solution'. Por lo tanto, cuando está en el modo ManualCompile, debe compilar manualmente cada proyecto que está modificando, lo que se puede hacer mediante haga clic derecho en cada proyecto afectado en el Explorador de soluciones y, a continuación, seleccione 'Build' o 'Rebuild'. Debería ver que sus tiempos de compilación globales ahora serán meros segundos.

Para que esta estrategia funcione, es necesario que el número de versión encontrado en los archivos AssemblyInfo y GlobalAssemblyInfo permanezca estático en la máquina del desarrollador (no durante las compilaciones de lanzamiento, por supuesto), y que no firme sus DLL.

Un riesgo potencial de usar esta estrategia manual de compilación es que el desarrollador puede olvidar compilar los proyectos requeridos, y cuando inicia el depurador, obtiene resultados inesperados (no se puede 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 ManualCompile durante las pruebas unitarias o para hacer cambios rápidos que sean de alcance limitado.

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

Teníamos más de 80 proyectos en nuestra solución principal que tardaron entre 4 y 6 minutos en construirse, dependiendo del tipo de máquina que estuviera trabajando un desarrollador. Consideramos que eso es demasiado largo: para cada prueba realmente se come sus FTEs.

Entonces, ¿cómo obtener tiempos de compilación más rápidos? Como parece que ya sabes, es el número 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 sourcefiles en uno. Pero tuvimos algunos proyectos que podríamos combinar sin embargo: Como cada "Proyecto de repositorio"en la solución tenía su propio proyecto unittest, simplemente combinamos todos los proyectos unittest en un proyecto global-unittest. Eso redujo el número de proyectos con alrededor de 12 proyectos y de alguna manera 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 debería simplemente incorpora todos los archivos utilizando carpetas de solución. Porque puede que te sorprenda ver el tiempo de construcción de esa nueva solución-con-solo-un-proyecto.

Sin embargo, trabajar con dos soluciones diferentes tomará 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 cuide su jerarquía de objetos, esta debería ser la solución donde su buildserver debería ejecutar todos tus unittests. Por lo tanto, el servidor para la Integración Continua debe ser el primer proyecto/solución. Tienes que mantener tu jerarquía de objetos, correcto.

La segunda solución con un solo proyecto (que se construirá mucho más rápido) será el proyecto donde las pruebas y la depuración serán realizadas por todos los desarrolladores. Usted tiene que cuidar de ellos mirando el buildserver sin embargo! Si algo se rompe, hay que arreglarlo.

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

También, tenga estos configurados para no copiar localmente excepto cuando sea absolutamente necesario (El proyecto maestro EXE).

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

Si está utilizando Visual Studio 2008, puede compilar usando el indicador /MP para construir un solo proyecto en paralelo. He leído que esta es también una característica indocumentada en Visual Studio 2005, pero nunca lo he intentado.

Puede construir varios proyectos en paralelo utilizando el indicador /M, pero esto por lo general ya se establece en el número de núcleos disponibles en la máquina, aunque esto solo se aplica a VC++ creo.

Noto que esta pregunta es muy antigua, pero el tema sigue siendo de interés hoy en día. El mismo problema me molestó últimamente, y las dos cosas que mejoraron más el rendimiento de compilación fueron (1) usar 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 las referencias del proyecto.

Algunos adicionales recursos:

• https://stackoverflow.com/questions/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

Algunas herramientas de análisis:

Herramientas- > opciones - > Configuración del proyecto VC++ - > Tiempo de compilación = Sí le dirá tiempo de construcción para cada vcproj.

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

Use /showIncludes para capturar includes anidados (archivos de encabezado que incluyen otros archivos de encabezado), y ver qué archivos podrían guardar una gran cantidad de IO mediante el uso de declaraciones de reenvío.

Esto le ayudará a optimizar el rendimiento del compilador mediante la eliminación de dependencias y 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 la RAM de sobra). Puede encontrar varios controladores de disco RAM gratuitos en la red. No encontrará ninguna unidad física, incluidas las SSD, que sea más rápida que un disco RAM.

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

La pequeña ganancia puede indicar que la compilación estaba vinculada a la CPU o que el almacenamiento en caché de archivos de Windows era bastante efectivo, pero ya que ambas pruebas se realizaron desde un estado donde los archivos no estaban almacenados en caché, me inclino fuertemente hacia compilaciones vinculadas a la CPU.

Dependiendo del código real que estás compilar su kilometraje puede variar so así que no dude en probar.

¿Qué tamaño tiene su directorio de compilación después de realizar una compilación completa? Si sigues con la configuración predeterminada, cada ensamblado que construyas 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, con mucho, la parte más costosa del proceso de compilación era copiar estos ensamblajes una y otra vez, y que una compilación podía generar gigabytes de copias del los mismos DLL una y otra vez.

Aquí hay algunos consejos útiles de Patrick Smacchia, autor de NDepend, sobre lo que él cree que deben y no deben ser asambleas separadas:

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

Básicamente hay dos maneras de solucionar esto, y ambas tienen inconvenientes. Una es reducir el número de asambleas, lo que obviamente es mucho trabajo. Otra es reestructurar sus directorios de compilación para que todas sus carpetas bin se consoliden y los proyectos no copien los archivos DLL de sus dependencias - no necesitan hacerlo porque ya están todos en el mismo directorio. Esto reduce drásticamente el número de archivos creados y copiados durante una compilación, pero puede ser difícil de configurar y puede dejarle con alguna dificultad para extraer solo las DLL requeridas por un ejecutable específico para el empaquetado.

Tal vez tomar algunas funciones comunes y hacer algunas bibliotecas, de esa manera las mismas fuentes no están siendo compiladas una y otra vez para múltiples proyectos.

Si le preocupa que se mezclen diferentes versiones de DLL, use bibliotecas estáticas.

Desactive la integración VSS. Es posible que no tenga una opción en su uso, pero DLLs conseguir "accidentalmente" renombrado todo el tiempo...

Y definitivamente compruebe la configuración de encabezado pre-compilado. 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

Tengo un proyecto que tiene 120 o más exes, libs y dll y toma un tiempo considerable para construir. Utilizo un árbol de archivos por lotes que llaman a make files desde un archivo por lotes maestro. He tenido problemas con cosas extrañas de encabezados incrementales (o era temperamental) en el pasado, así que los evito ahora. Hago una construcción completa con poca frecuencia, y por lo general lo dejo para el final del día mientras salgo a caminar durante una hora (así que solo puedo adivinar que tarda aproximadamente media hora). Así que entiendo por qué es inviable 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 but pero estos todavía llaman a los mismos archivos make. De vez en cuando puedo activar o desactivar la DEPURACIÓN y también decidir sobre compilaciones o marcas o si también quiero construir libs en las que el módulo pueda depender, y así sucesivamente.

El archivo por lotes también copia el resultado completado en las carpetas de prueba (o varias). 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 en realidad prefiero compilar desde la línea de comandos, a pesar de que estoy utilizando MS compliers.

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

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

Si se trata de una aplicación web, establecer la compilación por lotes en true puede ayudar dependiendo del escenario.

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

Puede encontrar un resumen aquí: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

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

Es decir:

Proyecto A referencias Proyecto B

Referencias del Proyecto B Proyecto C

Referencias del Proyecto C Proyecto A

Una alternativa más barata a Xoreax IB es el uso de lo que yo llamo uber-file builds. Es básicamente una .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 con cuántos #includes por archivo de uber tienen sentido. Depende de los proyectos. sucesivamente. Tal vez incluyas 10 archivos, tal vez 20.

Pagas un costo así que ten cuidado:

1. No puedes haga clic derecho en un archivo y diga " compile..."como tienes que excluir los archivos cpp individuales de la compilación e incluir solo los archivos cpp de uber
2. Hay que tener cuidado con los conflictos de variables globales estáticas.
3. Cuando añadas nuevos módulos, tienes que mantener los archivos uber actualizados

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

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

Mirando la máquina en la que está construyendo, ¿está configurada de manera óptima?

Acabamos de obtener nuestro tiempo de compilación para nuestro mayor producto de escala empresarial de C++ de 19 horas a 16 minutos asegurando que se instaló el controlador de filtro SATA correcto.

Sutil.

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

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

Ahora también estoy convencido de que hay un problema con VS2008. Lo estoy ejecutando en un portátil Intel de doble núcleo con 3G Ram, con antivirus desactivado. Compilar la solución a menudo es bastante ingenioso, pero si he estado depurando una recompilación posterior a menudo se ralentizará a un rastreo. Está claro por la luz continua del disco principal que hay un cuello de botella de E/S de disco (también se puede escuchar). Si cancelo la compilación y el apagado VS la actividad del disco se detiene. Reiniciar VS, recargar la solución y luego reconstruir, y es mucho más rápido. Unitl la próxima vez

Mis pensamientos son que este es un problema de paginación de memoria - VS simplemente se queda sin memoria y el O/S comienza el intercambio de páginas para tratar de hacer espacio, pero VS está exigiendo más de lo que el intercambio de páginas puede entregar, por lo que se ralentiza a un rastreo. No se me ocurre otra explicación.

VS definitivamente no es una herramienta RAD, ¿verdad?

Seguro que hay un problema con VS2008. Porque lo único que he hecho es instalar VS2008 para actualizar mi proyecto que ha sido 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

Buenas sugerencias que han ayudado hasta ahora (sin decir que no hay otras buenas sugerencias a continuación, si usted está teniendo problemas, recomiendo leer entonces, lo que nos ha ayudado)

• Nueva computadora portátil de 3GHz: el poder de la utilización perdida funciona de maravilla cuando se queja de la administración
• Desactivar Anti Virus durante la compilación
• 'Desconectar' de VSS (en realidad la red) durante la compilación - I puede hacer que eliminemos la integración de VS-VSS por completo y nos atengamos al uso del VSS UI

Todavía no se puede extraer información de una compilación, pero todo ayuda.

También estamos probando la práctica de construir nuevas áreas de la aplicación en nuevas soluciones, importando 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 creando soluciones temporales que solo encapsulan las áreas en las que necesitamos trabajar, y las desechan después de reintegrar el código. Nos necesitamos sopesar el tiempo que tomará reintegrar este código contra el tiempo que ganamos al no tener experiencias similares a Rip Van Winkle con la recompilación rápida durante el desarrollo.

Orion mencionó en un comentario que los genéricos también pueden tener una obra. A partir de mis pruebas, parece haber un impacto de 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 incluyen tantos genéricos, o tanto código, como aparecería en el sistema vivo, por lo que puede acumularse. No evitaría usar genéricos donde se supone que deben usarse, solo para el rendimiento en tiempo de compilación

Hay algunas cosas que he encontrado útiles para speading up C#/. NET builds:

• 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 NDepend si es necesario para controlar la llamada a través de capas)

• Haga que todos nuestros proyectos se construyan en el directorio de salida some y luego establezca" copiar local " en false en todas las referencias del proyecto – esto puede conducir a una gran velocidad debido a la reducción IO.

• Turno de su comprobador de virus para ver si hace mucha diferencia; si es así encontrar un comprobador de virus más rápido , o excluir las carpetas "caliente" de la exploración del comprobador de virus

• Utilice perforce monitor y la herramienta interna de sys para ver cómo sus compilaciones están tardando tanto.

• Considere un disco ram para poner su directorio de salida.

• Considere usar un SSD

• Más memoria puede tener un gran efecto a veces – (reducir la ram en la máquina si se obtiene una gran ralentización mediante la eliminación de un poco de ram, puede obtener una gran velocidad mediante la adición de más) Remove unneeded project references (es posible que tenga que eliminar "usings" innecesarios primero)

• Considere usar un marco de inyección de dependencias e interfaces para su capa de dominio más baja, por lo que solo se necesita una recompilación de todo cuando la interfaz cambia; esto puede no ganar mucho dependiendo de la frecuencia con la que se cambie la interfaz.