nous avons près de 100 projets dans une solution et un temps de construction dev de quelques secondes seulement:)

pour les constructions de développement local nous avons créé un addin de studio visuel qui change Project references en DLL references et décharge les projets indésirables (et une option pour les retourner naturellement).

• construisez notre solution entière une fois
• déchargez les projets sur lesquels nous ne travaillons pas actuellement et changez toutes les références de projets aux références DLL.
• avant le check-in, changer toutes les références de DLL vers les références de projet.

Notre construit maintenant que prendre quelques secondes lorsque l'on travaille sur quelques projets à la fois. Nous pouvons encore déboguer les projets supplémentaires car il est lié au débogage DLLs. L'outil prend généralement 10-30 secondes pour effectuer un grand nombre de changements, mais vous n'avez pas à le faire que souvent.

Mise À Jour Mai 2015

l'accord que j'ai fait (dans les commentaires ci-dessous), était que je voudrais libérer le plugin à Open Source si il obtient assez d'intérêt. 4 ans plus tard, il ne dispose que de 44 voix (et Visual Studio dispose désormais de deux versions successives), de sorte qu'il s'agit actuellement d'un projet de faible priorité.

j'ai eu un problème similaire sur une solution avec 21 projets et 1/2 millions de LOC. La plus grande différence était d'obtenir des disques durs plus rapides. De la performance monitor le ' Avg. La file d'attente de disque ' sauterait considérablement sur l'ordinateur portable indiquant que le disque dur était le goulot de la bouteille.

voici quelques données pour les temps de reconstruction totale...

1) Ordinateur Portable, Core 2 Duo 2GHz, lecteur 5400 RPM (pas sûr de cache. Était standard Dell inspiron).

temps de reconstruction = 112 secondes.

2) Bureau (standard), Core 2 Duo 2.3 Ghz, seul 7200 tr / min Lecteur de 8 mo de Cache.

temps de reconstruction = 72 secondes.

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

temps de reconstruction = 39 secondes.

la vitesse de 10 000 tr / min ne peut pas être sous-estimée. Construit où considérablement plus rapide plus Tout le reste comme l'affichage de la documentation, l'utilisation de file explorer a été remarquée plus rapidement. C'était une grosse augmentation de productivité en accélérant le cycle de construction-exécution de code.

Étant donné ce que les entreprises dépensent sur les salaires des développeurs, il est insensé combien ils peuvent gaspiller à les équiper avec les mêmes PC que la réceptionniste utilise.

pour les constructions C# .NET, vous pouvez utiliser .net Demon . C'est un produit qui prend en charge le processus de construction de Visual Studio pour le rendre plus rapide.

il fait cela en analysant les changements que vous avez faits, et construit seulement le projet que vous avez réellement changé, ainsi que d'autres projets qui ont réellement compté sur les changements que vous avez faits. Cela signifie que si vous ne modifiez que le code interne, un seul projet doit être construit.

éteignez votre antivirus. Cela ajoute de l'âge au temps de compilation.

utiliser une compilation distribuée. Xoreax IncrediBuild peut réduire le temps de compilation à quelques minutes.

Je l'ai utilisé sur une énorme solution C\C++ qui prend habituellement 5-6 heures à compiler. IncrediBuild a aidé à réduire ce temps à 15 minutes.

Instructions pour réduire le temps de compilation de votre Studio visuel à quelques secondes

Visual Studio n'est malheureusement pas assez intelligent pour distinguer les changements d'interface d'un assemblage des changements de corps de code sans conséquence. Ce fait, lorsqu'il est combiné avec de grandes solutions entrelacées, peut parfois créer une tempête parfaite de 'full-builds' indésirables presque chaque fois que vous changez une seule ligne de code.

une stratégie pour surmonter cela est de désactiver l'arbre de référence automatique construit. Pour ce faire, utilisez le Gestionnaire de Configuration (Build / Configuration Manager)...ensuite, dans la liste déroulante de configuration de la solution Active, choisissez "Nouveau") pour créer une nouvelle configuration de construction appelée "manuel compile" qui copie la configuration de débogage, mais ne cochez pas la case "Créer de nouvelles configurations de projet". Dans cette nouvelle configuration de build, décochez chaque projet de sorte qu'aucun d'entre eux va construire automatiquement. Sauvegardez cette configuration en appuyant sur 'Close'. Cette nouvelle configuration de construction est ajoutée à votre fichier solution.

vous pouvez passer d'une configuration de compilation à une autre via le menu déroulant de la configuration de compilation en haut de votre écran IDE (celui qui affiche habituellement 'Debug' ou 'Release'). En effet, cette nouvelle configuration manuelle rendra inutiles les options du menu de compilation pour: 'Build Solution' ou 'Rebuild Solution'. Ainsi, lorsque vous êtes en mode manuel compile, vous devez construire manuellement chaque projet que vous modifiez, ce qui peut être fait en cliquant avec le bouton droit de la souris sur chaque projet affecté dans L'Explorateur de solutions, puis en sélectionnant 'Build' ou 'Rebuild'. Vous devriez voir que vos temps de compilation globaux ne seront plus que de quelques secondes.

pour que cette stratégie fonctionne, il est nécessaire que le numéro de version trouvé dans les fichiers AssemblyInfo et GlobalAssemblyInfo reste statique sur la machine du développeur (et non pendant les compilations de Versions, bien sûr), et que vous ne signez pas vos DLLs.

un risque potentiel de l'utilisation de cette stratégie manuelle est que le développeur pourrait oublier de compiler les projets requis, et quand ils démarrent le débogueur, ils obtiennent des résultats inattendus (incapable de joindre le débogueur, les fichiers non trouvés, etc.). Pour éviter cela, il est probablement préférable d'utiliser la configuration de construction 'Debug' pour compiler un effort de codage plus important, et n'utiliser la configuration de construction manuelle que pendant les essais unitaires ou pour faire des changements rapides qui sont de portée limitée.

si c'est C ou C++, et que vous n'utilisez pas de headers précompilés, vous devriez l'être.

nous avions plus de 80 projets dans notre solution principale qui ont pris environ 4 à 6 minutes à construire selon le type de machine un développeur travaillait. Nous avons considéré que c'était beaucoup trop long: pour chaque test, il absorbe vraiment vos ETP.

alors comment obtenir des temps de construction plus rapides? Comme vous semblez sais déjà que c'est le nombre de projets qui ont vraiment du mal à la compilation. Bien sûr, nous ne voulions pas nous débarrasser de tous nos projets et simplement jeter toutes les sources dans un. Mais nous avons quand même pu combiner certains projets: comme chaque "projet de dépôt" de la solution avait son propre projet unittest, nous avons simplement combiné tous les projets unittest en un seul projet global unittest. Cela a permis de réduire le nombre de projets avec environ 12 projets et a permis d'économiser 40% du temps pour construire la solution entière.

nous pensons à une autre solution.

avez-vous également essayé de mettre en place une nouvelle (deuxième) solution avec un nouveau projet? Cette deuxième solution devrait tout simplement intégrer tous les fichiers en utilisant des dossiers de solution. Parce que vous pourriez être surpris de voir le moment de la construction de cette nouvelle solution-avec-juste-un-projet.

cependant, travailler avec deux solutions différentes prendra un certain soin. Les développeurs pourraient être enclins à réellement-travailler - dans la deuxième solution et complètement négliger la première. Comme la première solution avec le 70+ projets sera la solution qui prend soin de votre hiérarchie d'objets, ceci devrait être la solution où votre buildserver devrait exécuter tous vos unittests. Si le serveur pour l'Intégration Continue doit être le premier projet/solution. Tu dois maintenir ta hiérarchie d'objets, c'est ça.

la deuxième solution avec un seul projet (qui construira mucho PLUS VITE) sera le projet où les tests et le débogage seront effectués par tous les développeurs. Vous devez prendre soin d'eux en regardant le buildserver si! Si quoi que ce soit les pauses il DOIT être corrigé.

assurez-vous que vos références sont des références de projet, et pas directement aux DLLs dans les répertoires de sortie de bibliothèque.

aussi, avoir ceux-ci mis à ne pas copier localement sauf si absolument nécessaire (le projet master EXE).

j'ai posté cette réponse à l'origine ici: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Vous pouvez trouver de nombreux autres conseils utiles sur cette page.

si vous utilisez Visual Studio 2008, vous pouvez compiler en utilisant le drapeau /MP pour construire un seul projet en parallèle. J'ai lu que c'est également une fonctionnalité non documentée dans Visual Studio 2005, mais n'ai jamais essayé moi-même.

vous pouvez construire plusieurs projets en parallèle en utilisant le drapeau /M, mais cela est généralement déjà réglé sur le nombre de cœurs disponibles sur la machine, bien que cela ne s'applique qu'à VC++ je crois.

je remarque que cette question est vieux âges, mais le sujet est toujours d'intérêt aujourd'hui. Le même problème m'a mordu dernièrement, et les deux choses qui ont le plus amélioré la performance de construction étaient (1) utiliser un disque dédié (et rapide) pour compiler et (2) utiliser le même outputfolder pour tous les projets, et mettre CopyLocal à False sur les références de projet.

Quelques ressources supplémentaires:

• 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 /

quelques outils d'analyse:

outils->options->projet VC++ paramètres -> Build Timing = Oui vous dira construire le temps pour chaque vcproj.

ajouter /Bt passer à la ligne de commande du compilateur pour voir combien chaque fichier CPP a pris

utilisez /showIncludes pour saisir les inclusions emboîtées (les fichiers d'en-tête qui incluent d'autres fichiers d'en-tête), et voyez quels fichiers pourraient enregistrer beaucoup D'IO en utilisant des déclarations forward.

Cela vous aidera à optimiser la performance du compilateur en éliminant les dépendances et les bogues de performance.

avant de dépenser de l'argent pour investir dans des disques durs plus rapides, essayez de construire votre projet entièrement sur un disque RAM (en supposant que vous avez la RAM à épargner). Vous pouvez trouver divers pilotes de disque RAM gratuit sur le net. Vous ne trouverez aucun lecteur physique, y compris les SSD, qui sont plus rapides qu'un disque RAM.

dans mon cas, un projet qui a pris 5 minutes pour construire sur un i7 6-core sur un lecteur SATA 7200 RPM Avec Incredibuild a été réduit d'environ seulement 15 secondes en utilisant un disque RAM. Compte tenu de la nécessité de recopier à un stockage permanent et le potentiel de travail perdu, 15 secondes n'est pas assez incitation à utiliser un disque RAM et probablement pas beaucoup incitation à dépenser plusieurs centaines de dollars sur un haut-RPM ou SSD Lecteur.

le petit gain peut indiquer que la construction était liée au CPU ou que la mise en cache du fichier Windows était plutôt efficace, mais puisque les deux tests ont été faits à partir d'un état où les fichiers n'étaient pas mis en cache, je penche fortement vers les compilations liées au CPU.

selon le code que vous compilez, votre kilométrage peut varier, alors n'hésitez pas à tester.

Quelle est la taille de votre répertoire de compilation après une compilation complète? Si vous vous en tenez à la configuration par défaut, alors chaque assemblée que vous construisez copiera tous les DLLs de ses dépendances et des dépendances de ses dépendances, etc. à son répertoire bin. Dans mon travail précédent, lorsque je travaillais avec une solution de ~40 projets, mes collègues ont découvert que de loin la partie la plus coûteuse du processus de construction était de copier ces assemblages encore et encore, et qu'une construction pouvait générer des gigaoctets de copies. de la même Dll, encore et encore.

voici quelques conseils utiles de Patrick Smacchia, l'auteur de NDepend, sur ce qu'il croit devrait et ne devrait pas être assemblées séparées:

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

il y a essentiellement deux façons de contourner cela, et les deux ont des inconvénients. L'un est de réduire le nombre de assemblées, ce qui est évidemment beaucoup de travail. Une autre est de restructurer vos répertoires de construction de sorte que tous vos dossiers bin soient consolidés et que les projets ne copient pas les DLLs de leurs dépendances - ils n'en ont pas besoin parce qu'ils sont déjà tous dans le même répertoire. Cela réduit considérablement le nombre de fichiers créés et copiés pendant une compilation, mais cela peut être difficile à configurer et cela peut vous laisser avec de la difficulté à extraire seulement les DLLs requis par un exécutable spécifique pour l'empaquetage.

peut-être prendre quelques fonctions communes et faire quelques bibliothèques, de cette façon les mêmes sources ne sont pas compilées encore et encore pour des projets multiples.

si vous craignez que différentes versions de DLLs ne soient mélangées, utilisez des bibliothèques statiques.

désactiver l'intégration VSS. Vous n'avez peut-être pas le choix de l'utiliser, mais les DLLs sont "accidentellement" renommés tout le temps...

et vérifiez certainement vos paramètres d'en-tête pré-compilés. Le guide de Bruce Dawson est un peu vieux, mais tout de même très bon-vérifier: http://www.cygnus-software.com/papers/precompiledheaders.html

j'ai un projet qui a 120 exes ou plus, libs et dlls et prend un temps considérable à construire. J'utilise un arbre de dossiers de fournée qui appellent font des dossiers d'un dossier de fournée principal. J'ai eu des problèmes avec les choses étranges de incrémental (ou était-il Capricieux) headers dans le passé, donc je les évite maintenant. Je fais une construction complète rarement, et généralement le laisser à la fin de la journée pendant que je vais faire une promenade d'une heure (donc je ne peux deviner que cela prend environ une demi-heure). Donc, je comprends pourquoi est impraticable pour le travail et les tests.

pour travailler et tester j'ai un autre ensemble de fichiers batch pour chaque application (ou module ou bibliothèque) qui ont aussi tous les paramètres de débogage en place -- mais ceux-ci appellent toujours les mêmes fichiers make. Je peux activer ou désactiver le débogage de temps en temps et décider aussi des constructions ou des makes ou si je veux aussi construire des libs dont le module peut dépendre, et ainsi de suite.

le fichier de lot copie également le résultat complété dans le (ou plusieurs) dossiers de test. Selon les réglages, cela se termine en quelques secondes à une minute (par opposition à une demi-heure).

j'ai utilisé un IDE (Zeus) différent car j'aime avoir le contrôle sur des choses comme .les fichiers rc, et en fait préfèrent compiler à partir de la ligne de commande, même si j'utilise MS compliers.

heureux de poster un exemple de ce fichier batch si quelqu'un est intéressé.

Désactiver le système de fichiers d'indexation des répertoires source (en particulier les obj répertoires, si vous voulez que votre source consultable)

s'il s'agit d'une application web, configurer la compilation par lots à true peut aider en fonction du scénario.

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

vous pouvez trouver un aperçu ici: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

vous pouvez également vérifier les références de projets circulaires. Il a été un problème pour moi une fois.

C'est-à-dire:

projet a références projet B

projet B références projet c

projet c références projet a

une alternative moins chère à Xoreax IB est l'utilisation de ce que j'appelle Uber-construction de fichiers. C'est essentiellement un .fichier cpp qui a

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

puis vous compilez les unités uber à la place des modules individuels. Nous avons vu des temps de compilation de 10-15 minutes à 1-2 minutes. Vous pourriez avoir à expérimenter avec combien de # includes par fichier font du sens. Dépend des projets. etc. Peut-être que vous incluez 10 dossiers, peut-être 20.

vous payez un coût alors méfiez-vous:

1. vous ne pouvez pas faire un clic droit sur un fichier et dire "compiler"..."comme vous devez exclure les fichiers cpp individuels de la compilation et inclure seulement les fichiers cpp uber
2. vous devez faire attention aux conflits statiques de variables globales.
3. lorsque vous ajoutez de nouveaux modules, vous devez garder les fichiers uber à jour

c'est un peu une douleur, mais pour un projet qui est largement statique en termes de nouveaux modules, la douleur initiale pourrait en valoir la peine. J'ai vu cette méthode battre IB dans certains cas.

si c'est un projet C++, alors vous devriez utiliser des en-têtes précompilés. Cela fait une énorme différence dans les temps de compilation. Pas sûr de ce que cl.exe fait vraiment (sans utiliser de headers précompilés), il semble être à la recherche de lots de headers STL dans tous les mauvais endroits avant d'aller finalement à l'endroit correct. Cela ajoute des secondes entières à chaque simple .rpc fichier compilé. Vous ne savez pas si c'est un cl.exe bug, ou une sorte de problème STL dans VS2008.

en regardant la machine sur laquelle vous construisez, est-elle configurée de manière optimale?

nous venons d'obtenir notre temps de construction pour notre plus grand produit C++ à l'échelle de l'entreprise de 19 heures à 16 minutes en s'assurant que le pilote de filtre SATA droit a été installé.

subtil.

There's undocumented / MP switch in Visual Studio 2005, see http://lahsiv.net/blog/?p=40 , qui permettrait une compilation parallèle sur la base du dossier plutôt que sur la base du projet. Cela peut accélérer la compilation de ce dernier projet, ou, si vous compilez un projet.

lors du choix d'une taille de cache CPU: L1 semble avoir un impact énorme sur le temps de compilation. En outre,il est généralement mieux d'avoir 2 noyaux rapides que 4 lents. Visual Studio n'utilise pas les noyaux supplémentaires très efficacement. (Je base cela sur mon expérience avec le compilateur C++, mais c'est probablement aussi vrai pour le C# one.)

je suis également convaincu qu'il y a un problème avec VS2008. Je l'exécute sur un portable Intel Double noyau avec Ram 3g, avec anti-virus éteint. Compiler la solution est souvent assez délicat, mais si j'ai été déboguer un recompilé ultérieur ralentira souvent à un crawl. Il est clair d'après la lumière continue du disque principal qu'il y a un goulot d'étranglement d'E/S du disque (vous pouvez l'entendre, aussi). Si j'annule la compilation et l'arrêt par rapport à l'activité du disque s'arrête. Redémarrez VS, rechargez la solution et ensuite reconstruire, et il est beaucoup plus rapide. Unitl la prochaine fois

mes pensées sont qu'il s'agit d'un problème de pagination de mémoire - VS juste s'épuise de mémoire et le O/S commence page swapping pour essayer de faire de l'espace, mais VS est exigeant plus que page swapping peut livrer, de sorte qu'il ralentit vers le bas à un crawl. Je ne vois pas d'autre explication.

VS n'est certainement pas un outil RAD, n'est-ce pas?

il est sûr qu'il y a un problème avec VS2008. Parce que la seule chose que j'ai faite c'est d'installer VS2008 pour mettre à jour mon projet qui a été créé avec VS2005. Je n'ai que deux projets dans ma solution. Il n'est pas grand. Compilation avec VS2005: 30 secondes Compilation avec VS2008: 5 minutes

Nice suggestions qui ont aidé à ce jour (ne pas qu'il n'y a pas d'autres excellentes suggestions ci-dessous, si vous rencontrez des problèmes, je vous recommande la lecture puis, juste ce qui nous a permis d')

• nouveau portable 3GHz-le pouvoir de la perte d'utilisation fait des merveilles quand se plaindre à la direction
• Désactiver l'Anti Virus lors de la compilation
• 'déconnexion' de VSS (en fait le réseau) pendant la compilation - je peux nous faire supprimer VS-VSS intégration tout à fait et s'en tenir à l'utilisation de L'interface utilisateur VSS

toujours pas de rip-sniting à travers une compilation, mais chaque peu aide.

nous testons également la pratique de construire de nouveaux domaines d'application dans de nouvelles solutions, l'importation dans les dernières dlls si nécessaire, les intégrer dans la solution plus grande lorsque nous sommes heureux avec eux.

nous pouvons aussi les faire de la même façon au code existant en créant temporaire des solutions qui ne font qu'englober les domaines sur lesquels nous devons travailler et les jeter après avoir réintégré le code. Nous devons évaluer le temps qu'il faudra pour réintégrer ce code par rapport au temps que nous gagnerons à ne pas avoir Rip Van Winkle comme des expériences de recompilation rapide pendant le développement.

Orion a mentionné dans un commentaire que generics peut avoir un jeu aussi. D'après mes tests, il semble y avoir une performance minimale, mais pas assez élevée pour être sûr - compiler des temps peut être incohérent en raison de l'activité du disque. En raison des limites de temps, mes tests n'ont pas inclus autant de génériques, ou autant de code, que ce qui apparaîtrait dans le système en direct, donc cela peut s'accumuler. Je n'éviterais pas d'utiliser des génériques là où ils sont censés être utilisés, juste pour les performances de compilation

il y a quelques choses que j'ai trouvées utiles pour accélérer C# /.NET construit:

• combinez les petits projets en grands projets car il y a un grand par projet de frais généraux sur la construction d'une solution. (Utilisez nDepend si nécessaire pour contrôler l'appel entre les couches)

• faites en sorte que tous nos projets soient intégrés dans le répertoire de sortie et mettez" copie local " à false sur toutes les références de projet – cela peut conduire à une grande vitesse en raison D'IO réduit.

• Tour de votre anti-virus pour voir si cela fait une grande différence; si donc trouver un plus rapide du virus checker , ou de les en exclure "à chaud" des dossiers à partir du logiciel de détection de virus de la numérisation

• utilisez perforce monitor et l'outil interne du système pour voir comment vos compilations prennent autant de temps.

• considérez un disque ram pour mettre votre répertoire de sortie sur.

• envisager l'utilisation D'un SSD

• plus de mémoire peut avoir un grand effet à certains moments – (réduire la mémoire vive dans la machine si vous obtenez un grand ralentissement en enlevant un peu de mémoire vive, vous pouvez obtenir une grande vitesse en ajoutant plus) Supprimer les références non nécessaires au projet (vous pourriez devoir supprimer les "utilisations" non nécessaires en premier)

• envisagez d'utiliser un framework d'injection de dépendances et des interfaces pour votre couche de domaine la plus basse, de sorte qu'une recompilation de tout n'est nécessaire que lorsque l'interface change – cela peut ne pas rapporter beaucoup en fonction de la fréquence à laquelle l'interface est changée.