Nous obtenons des temps de compilation très lents, qui peuvent prendre plus de 20 minutes sur les machines double cœur 2 GHz, 2G Ram.

Cela est dû en grande partie à la taille de notre solution qui est passée à plus de 70 projets, ainsi qu'à VSS qui est un goulot d'étranglement en soi lorsque vous avez beaucoup de fichiers. (échanger VSS n'est malheureusement pas une option, donc je ne veux pas que cela descende dans une bash VSS)

Nous envisageons de fusionner des projets. Nous cherchons également à avoir plusieurs solutions pour obtenir une plus grande séparation des préoccupations et des temps de compilation plus rapides pour chaque élément de l'application. Ce que je peux voir deviendra un enfer DLL alors que nous essayons de garder les choses synchronisées.

Je suis intéressé de savoir comment d'autres équipes ont géré ce problème de mise à l'échelle, que faites-vous lorsque votre base de code atteint une masse critique que vous perdez la moitié de la journée à regarder la barre d'état livrer des messages de compilation.

MISE À JOUR J'ai négligé de mentionner qu'il s'agit d'une solution C #. Merci pour toutes les suggestions C ++, mais cela fait quelques années que je n'ai plus à me soucier des en-têtes.

ÉDITER:

Bonnes suggestions qui ont aidé jusqu'à présent (sans dire qu'il n'y a pas d'autres bonnes suggestions ci-dessous, juste ce qui a aidé)

• Nouvel ordinateur portable 3GHz - la puissance de la perte d'utilisation fait des merveilles lorsque vous vous plaignez de la direction
• Désactiver l'antivirus lors de la compilation
• `` Déconnexion '' de VSS (en fait le réseau) pendant la compilation - je peux nous amener à supprimer complètement l'intégration VS-VSS et à nous en tenir à l'utilisation de l'interface utilisateur VSS

Toujours pas de rip-snort à travers une compilation, mais chaque bit aide.

Orion a mentionné dans un commentaire que les génériques peuvent aussi avoir un jeu. D'après mes tests, il semble y avoir un impact minimal sur les performances, mais pas assez élevé pour être sûr - les temps de compilation peuvent être incohérents en raison de l'activité du disque. En raison des limites de temps, mes tests n'incluaient pas autant de génériques, ou autant de code, que cela apparaîtrait dans le système en direct, de sorte que 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

SOLUTION DE CONTOURNEMENT

Nous testons la pratique consistant à créer de nouveaux domaines de l'application dans de nouvelles solutions, en important les dernières DLL selon les besoins, en les intégrant dans la solution plus large lorsque nous en sommes satisfaits.

Nous pouvons également les faire de même avec le code existant en créant des solutions temporaires qui encapsulent simplement les domaines sur lesquels nous devons travailler et en les jetant après la réintégration du code. Nous devons peser le temps qu'il faudra pour réintégrer ce code par rapport au temps que nous gagnons en n'ayant pas Rip Van Winkle comme des expériences de recompilation rapide pendant le développement.

L'équipe Chromium.org a répertorié plusieurs options pour accélérer la construction (à ce stade, environ à mi-chemin de la page):

Par ordre décroissant d'accélération:

• Installez le correctif Microsoft 935225 .
• Installez le correctif Microsoft 947315 .
• Utilisez un véritable processeur multicœur (c'est-à-dire un Intel Core Duo 2, pas un Pentium 4 HT).
• Utilisez 3 versions parallèles. Dans Visual Studio 2005, vous trouverez l'option dans Outils> Options ...> Projets et solutions> Générer et exécuter> nombre maximal de générations de projets parallèles .
• Désactivez votre logiciel antivirus pour les fichiers .ilk, .pdb, .cc, .h et ne recherchez les virus que lors de la modification . Désactivez l'analyse du répertoire où résident vos sources. Ne fais rien de stupide.
• Stockez et créez le code Chromium sur un deuxième disque dur. Cela n'accélérera pas vraiment la compilation, mais au moins votre ordinateur restera réactif lorsque vous effectuez une synchronisation gclient ou une compilation.
• Défragmentez régulièrement votre disque dur.
• Désactivez la mémoire virtuelle.

Nous avons près de 100 projets dans une seule solution et un temps de développement de seulement quelques secondes :)

Pour le développement local construit nous avons créé un Visual Studio Addin que les changements Project referencesà DLL referenceset déchargements les projets indésirables (et une option pour les passer en arrière bien sûr).

• Construisez une fois notre solution complète
• Déchargez les projets sur lesquels nous ne travaillons pas actuellement et modifiez toutes les références de projet en références DLL.
• Avant l'archivage, modifiez toutes les références de DLL aux références de projet.

Nos builds ne prennent maintenant que quelques secondes lorsque nous ne travaillons que sur quelques projets à la fois. Nous pouvons également toujours déboguer les projets supplémentaires car ils sont liés aux DLL de débogage. L'outil prend généralement 10 à 30 secondes pour effectuer un grand nombre de modifications, mais vous n'avez pas à le faire aussi souvent.

Mise à jour mai 2015

L'accord que j'ai fait (dans les commentaires ci-dessous) était que je publierais le plugin en Open Source s'il suscite suffisamment d'intérêt. 4 ans plus tard, il n'a que 44 votes (et Visual Studio a maintenant deux versions ultérieures), il s'agit donc actuellement d'un projet de faible priorité.

J'ai eu un problème similaire sur une solution avec 21 projets et 1/2 million de LOC. La plus grande différence était d'obtenir des disques durs plus rapides. Depuis le moniteur de performances, le 'Avg. Disk Queue »sauterait de manière significative sur l'ordinateur portable indiquant que le disque dur était le goulot de la bouteille.

Voici quelques données pour les temps de reconstruction totaux ...

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

Temps de reconstruction = 112 secondes.

2) Bureau (problème standard), Core 2 Duo 2,3 GHz, cache unique de 8 Mo de lecteur 7200 tr / min.

Temps de reconstruction = 72 secondes.

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

Temps de reconstruction = 39 secondes.

Le lecteur de 10 000 tr / min ne peut être sous-estimé. Constructions où beaucoup plus rapides et tout le reste comme l'affichage de la documentation, l'utilisation de l'explorateur de fichiers était plus rapide. C'était une grosse augmentation de la productivité en accélérant le cycle de création de code.

Compte tenu de ce que les entreprises dépensent pour les salaires des développeurs, il est insensé de savoir combien elles peuvent gaspiller en les équipant des mêmes ordinateurs que ceux utilisés par la réceptionniste.

Pour les versions C # .NET, vous pouvez utiliser .NET Demon . C'est un produit qui prend en charge le processus de génération de Visual Studio pour le rendre plus rapide.

Pour ce faire, il analyse les modifications que vous avez apportées et ne génère que le projet que vous avez réellement modifié, ainsi que d'autres projets qui reposaient réellement sur les modifications que vous avez apportées. Cela signifie que si vous ne modifiez que le code interne, un seul projet doit être généré.

Éteignez votre antivirus. Cela ajoute des âges au temps de compilation.

Utilisez la 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 généralement 5-6 heures à compiler. IncrediBuild a aidé à réduire ce temps à 15 minutes.

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

Visual Studio n'est malheureusement pas assez intelligent pour distinguer les modifications d'interface d'un assembly des modifications 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 «builds complets» indésirables presque chaque fois que vous modifiez une seule ligne de code.

Une stratégie pour surmonter cela consiste à désactiver les constructions automatiques de l'arbre de référence. Pour ce faire, utilisez le 'Configuration Manager' (Build / Configuration Manager ... puis dans la liste déroulante de configuration de la solution active, choisissez 'New') pour créer une nouvelle configuration de construction appelée 'ManualCompile' qui copie de la configuration de débogage, mais faites ne cochez pas la case «Créer de nouvelles configurations de projet». Dans cette nouvelle configuration de construction, décochez chaque projet afin qu'aucun d'entre eux ne soit construit automatiquement. Enregistrez cette configuration en cliquant sur «Fermer». Cette nouvelle configuration de construction est ajoutée à votre fichier de solution.

Vous pouvez passer d'une configuration de construction à une autre via le menu déroulant de configuration de construction en haut de votre écran IDE (celui qui affiche généralement soit «Debug» ou «Release»). En effet, cette nouvelle configuration de build ManualCompile rendra inutiles les options du menu Build pour: 'Build Solution' ou 'Rebuild Solution'. Ainsi, lorsque vous êtes en mode ManualCompile, vous devez créer 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 «Construire» ou «Reconstruire». Vous devriez voir que vos temps de compilation globaux ne seront plus que 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 (pas pendant les versions de version bien sûr) et que vous ne signez pas vos DLL.

Un risque potentiel de l'utilisation de cette stratégie ManualCompile est que le développeur peut oublier de compiler les projets requis, et quand ils démarrent le débogueur, ils obtiennent des résultats inattendus (impossible de joindre le débogueur, 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 d'utiliser uniquement la configuration de construction ManualCompile pendant les tests unitaires ou pour apporter des modifications rapides de portée limitée.

S'il s'agit de C ou C ++ et que vous n'utilisez pas d'en-têtes précompilés, vous devriez l'être.

Nous avions plus de 80 projets dans notre solution principale qui prenaient environ 4 à 6 minutes à construire en fonction du type de machine qu'un développeur travaillait. Nous avons considéré que c'était beaucoup trop long: pour chaque test, cela ronge vraiment vos ETP.

Alors, comment accélérer les temps de construction? Comme vous semblez le savoir déjà, c'est le nombre de projets qui nuit vraiment au buildtime. Bien sûr, nous ne voulions pas nous débarrasser de tous nos projets et simplement jeter tous les fichiers source en un seul. Mais nous avions quelques projets que nous pouvions néanmoins combiner: comme chaque «projet de référentiel» dans la solution avait son propre projet unittest, nous avons simplement combiné tous les projets unittest dans un projet global-unittest. Cela a réduit le nombre de projets avec environ 12 projets et a en quelque sorte économisé 40% du temps pour construire la solution entière.

Nous réfléchissons cependant à 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 simplement incorporer tous les fichiers utilisant des dossiers de solution. Parce que vous pourriez être surpris de voir le temps de construction de cette nouvelle solution-avec-juste-un-projet.

Cependant, travailler avec deux solutions différentes nécessitera une attention particulière. Les développeurs pourraient être enclins à réellement - travailler - dans la deuxième solution et à négliger complètement la première. Comme la première solution avec plus de 70 projets sera la solution qui prend en charge votre hiérarchie d'objets, cela devrait être la solution où votre serveur de build devrait exécuter tous vos unittests. Le serveur pour l'intégration continue doit donc être le premier projet / solution. Vous devez maintenir votre hiérarchie d'objets, n'est-ce pas.

La deuxième solution avec un seul projet (qui se construira beaucoup plus rapidement) sera le projet où les tests et le débogage seront effectués par tous les développeurs. Vous devez cependant vous en occuper en regardant le serveur de construction! Si quelque chose casse, il DOIT être réparé.

Assurez-vous que vos références sont des références de projet et non directement aux DLL dans les répertoires de sortie de la bibliothèque.

En outre, configurez-les pour ne pas copier localement, sauf lorsque cela est absolument nécessaire (le projet EXE principal).

J'ai publié cette réponse à l'origine ici: /programming/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 à l'aide de l'indicateur / MP pour créer un seul projet en parallèle. J'ai lu qu'il s'agit également d'une fonctionnalité non documentée dans Visual Studio 2005, mais je n'ai jamais essayé moi-même.

Vous pouvez créer plusieurs projets en parallèle en utilisant l'indicateur / M, mais cela est généralement déjà défini 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 ancienne, mais le sujet est toujours d'actualité. Le même problème m'a mordu récemment, et les deux choses qui ont le plus amélioré les performances de construction étaient (1) utiliser un disque dédié (et rapide) pour la compilation et (2) utiliser le même dossier de sortie pour tous les projets, et définir CopyLocal sur False sur le projet références.

Quelques ressources supplémentaires:

• /programming/8440/visual-studio-optimisations
• 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:

tools-> options-> Paramètres du projet VC ++ -> Build Timing = Yes vous indiquera l'heure de construction pour chaque vcproj.

Ajoutez un /Btcommutateur à la ligne de commande du compilateur pour voir combien chaque fichier CPP a pris

Utilisez /showIncludespour intercepter les inclusions imbriquées (fichiers d'en-tête qui incluent d'autres fichiers d'en-tête) et voir quels fichiers pourraient enregistrer beaucoup d'E / S en utilisant des déclarations directes.

Cela vous aidera à optimiser les performances du compilateur en éliminant les dépendances et les problèmes de performances.

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 ayez de la RAM à revendre). Vous pouvez trouver divers pilotes de disque RAM gratuits sur le net. Vous ne trouverez aucun lecteur physique, y compris les SSD, plus rapide qu'un disque RAM.

Dans mon cas, un projet qui prenait 5 minutes à construire sur un i7 6 cœurs sur un lecteur SATA à 7200 tr / min avec Incredibuild a été réduit d'environ 15 secondes seulement en utilisant un disque RAM. Compte tenu de la nécessité de recopier sur un stockage permanent et du potentiel de perte de travail, 15 secondes ne sont pas suffisamment incitatives à utiliser un disque RAM et probablement pas beaucoup d'incitation à dépenser plusieurs centaines de dollars sur un disque SSD ou à haut régime.

Le petit gain peut indiquer que la construction était liée au processeur ou que la mise en cache des fichiers Windows était plutôt efficace, mais comme les deux tests ont été effectués à partir d'un état où les fichiers n'étaient pas mis en cache, je me penche fortement vers les compilations liées au processeur.

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 construction après avoir effectué une compilation complète? Si vous vous en tenez à la configuration par défaut, chaque assembly que vous construisez copiera toutes les DLL de ses dépendances et les dépendances de ses dépendances, etc. dans son répertoire bin. Dans mon travail précédent, lorsque je travaillais avec une solution d'environ 40 projets, mes collègues ont découvert que la partie de loin la plus coûteuse du processus de construction consistait à copier ces assemblys encore et encore, et qu'une version pouvait générer des gigaoctets de copies des mêmes DLL sur et à nouveau.

Voici quelques conseils utiles de Patrick Smacchia, auteur de NDepend, sur ce qui, selon lui, devrait et ne devrait pas être des assemblées séparées:

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

Il existe essentiellement deux façons de contourner ce problème, et les deux présentent des inconvénients. L'une consiste à réduire le nombre d'assemblages, ce qui représente évidemment beaucoup de travail. Une autre consiste à restructurer vos répertoires de construction afin que tous vos dossiers bin soient consolidés et que les projets ne copient pas les DLL de leurs dépendances - ils n'en ont pas besoin car 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 peut vous laisser avec quelques difficultés à extraire uniquement les DLL requises par un exécutable spécifique pour l'empaquetage.

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

Si vous craignez que différentes versions de DLL soient confondues, utilisez des bibliothèques statiques.

Désactivez l'intégration VSS. Vous n'avez peut-être pas le choix de l'utiliser, mais les DLL sont renommées «accidentellement» 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 toujours très bon - consultez-le: http://www.cygnus-software.com/papers/precompiledheaders.html

J'ai un projet qui a 120 exes, libs et dll ou plus et prend un temps considérable à construire. J'utilise une arborescence de fichiers batch qui appellent make files à partir d'un fichier batch master. J'ai eu des problèmes avec des choses étranges provenant d'en-têtes incrémentiels (ou était-ce capricieux) dans le passé, alors je les évite maintenant. Je fais rarement une construction complète et je la laisse généralement à la fin de la journée pendant que je me promène pendant une heure (donc je ne peux que deviner que cela prend environ une demi-heure). Je comprends donc pourquoi cela ne fonctionne pas 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 également 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 DEBUG de temps en temps et décider également des builds ou des marques ou si je veux également construire des bibliothèques dont le module peut dépendre, et ainsi de suite.

Le fichier de commandes copie également le résultat terminé dans le (ou plusieurs) dossiers de test. Selon les paramètres, cela se termine en quelques secondes à une minute (par opposition à une demi-heure).

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

Heureux de publier un exemple de ce fichier batch si quelqu'un est intéressé.

Désactivez l'indexation du système de fichiers sur vos répertoires source (en particulier les répertoires obj si vous souhaitez que votre source puisse être recherchée)

S'il s'agit d'une application Web, la définition de la génération par lots sur 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 rechercher des références de projet circulaires. C'était un problème pour moi une fois.

C'est:

Le projet A fait référence au projet B

Projet B fait référence au projet C

Le projet C fait référence au projet A

Une alternative moins chère à Xoreax IB est l'utilisation de ce que j'appelle des builds uber-file. C'est essentiellement un fichier .cpp qui a

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

Ensuite, vous compilez les unités uber au lieu des modules individuels. Nous avons vu des temps de compilation de 10 à 15 minutes jusqu'à 1 à 2 minutes. Vous devrez peut-être tester le nombre de #includes par fichier uber qui a du sens. Dépend des projets. etc. Peut-être que vous incluez 10 fichiers, peut-être 20.

Vous payez un prix alors méfiez-vous:

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

C'est un peu pénible, mais pour un projet qui est en grande partie 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.

S'il s'agit d'un projet C ++, vous devez utiliser des en-têtes précompilés. Cela fait une énorme différence dans les temps de compilation. Je ne sais pas vraiment ce que fait cl.exe (sans utiliser d'en-têtes précompilés), il semble rechercher beaucoup d'en-têtes STL aux mauvais endroits avant d'aller enfin au bon emplacement. Cela ajoute des secondes entières à chaque fichier .cpp en cours de compilation. Je ne sais pas s'il s'agit d'un bogue cl.exe ou d'un problème STL dans VS2008.

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

Nous venons de réduire le temps de construction de notre plus grand produit C ++ à l'échelle de l'entreprise de 19 heures à 16 minutes en nous assurant que le bon pilote de filtre SATA a été installé.

Subtil.

Il existe un commutateur / MP non documenté dans Visual Studio 2005, voir http://lahsiv.net/blog/?p=40 , qui permettrait la compilation parallèle sur la base de fichiers plutôt que sur la base de projets. Cela peut accélérer la compilation du dernier projet ou, si vous compilez un projet.

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

Je suis également maintenant convaincu qu'il y a un problème avec VS2008. Je l'exécute sur un ordinateur portable Intel dual core avec 3G Ram, avec anti-virus désactivé. Compiler la solution est souvent assez simple, mais si j'ai débogué, une recompilation ultérieure ralentira souvent en une analyse. Le voyant du disque principal continu indique clairement qu'il existe un goulot d'étranglement d'E / S disque (vous pouvez également l'entendre). Si j'annule la construction et l'arrêt VS, l'activité du disque s'arrête. Redémarrez VS, rechargez la solution puis reconstruisez, et c'est beaucoup plus rapide. Unitl la prochaine fois

Je pense qu'il s'agit d'un problème de pagination de la mémoire - VS manque juste de mémoire et le système d'exploitation commence l'échange de pages pour essayer de gagner de la place, mais VS exige plus que ce que l'échange de pages peut offrir, il ralentit donc jusqu'à une exploration. Je ne peux penser à aucune autre explication.

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

Votre entreprise utilise-t-elle Entrust pour sa solution PKI / cryptage par hasard? Il s'avère que nous avions des performances de construction épouvantables pour un site Web assez volumineux construit en C #, prenant plus de 7 minutes sur un Rebuild-All.

Ma machine est un i7-3770 avec 16 Go de RAM et un SSD de 512 Go, les performances n'auraient donc pas dû être si mauvaises. J'ai remarqué que mes temps de construction étaient incroyablement plus rapides sur une machine secondaire plus ancienne construisant la même base de code. J'ai donc lancé ProcMon sur les deux machines, profilé les versions et comparé les résultats.

Et voilà, la machine à exécution lente avait une différence - une référence à Entrust.dll dans le stacktrace. En utilisant ces informations nouvellement acquises, j'ai continué à rechercher StackOverflow et j'ai trouvé ceci: MSBUILD (VS2010) très lent sur certaines machines . Selon la réponse acceptée, le problème réside dans le fait que le gestionnaire Entrust traitait les vérifications de certificat .NET au lieu du gestionnaire Microsoft natif. Il est également suggéré qu'Entrust v10 résout ce problème qui prévaut dans Entrust 9.

Je l'ai actuellement désinstallé et mes temps de construction ont chuté à 24 secondes . YYMV avec le nombre de projets que vous construisez actuellement et peut ne pas résoudre directement le problème de mise à l'échelle sur lequel vous vous êtes renseigné. Je publierai une modification de cette réponse si je peux fournir un correctif sans recourir à une désinstallation du logiciel.

C'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 2 projets dans ma solution. Ce n'est pas grand. Compilation avec VS2005: 30 secondes Compilation avec VS2008: 5 minutes

Bonnes suggestions qui ont aidé jusqu'à présent (sans dire qu'il n'y a pas d'autres bonnes suggestions ci-dessous, si vous rencontrez des problèmes, je vous recommande de lire alors, ce qui nous a aidés)

• Nouvel ordinateur portable 3GHz - la puissance de la perte d'utilisation fait des merveilles lorsque vous vous plaignez de la direction
• Désactiver l'antivirus lors de la compilation
• `` Déconnexion '' de VSS (en fait le réseau) pendant la compilation - je peux nous amener à supprimer complètement l'intégration VS-VSS et à nous en tenir à l'utilisation de l'interface utilisateur VSS

Toujours pas de rip-snort à travers une compilation, mais chaque bit aide.

Nous testons également la pratique consistant à créer de nouveaux domaines de l'application dans de nouvelles solutions, en important les dernières DLL selon les besoins, en les intégrant dans la solution plus large lorsque nous en sommes satisfaits.

Nous pouvons également les faire de même avec le code existant en créant des solutions temporaires qui encapsulent simplement les domaines sur lesquels nous devons travailler et en les jetant après la réintégration du code. Nous devons peser le temps qu'il faudra pour réintégrer ce code par rapport au temps que nous gagnons en n'ayant pas Rip Van Winkle comme des expériences de recompilation rapide pendant le développement.

Orion a mentionné dans un commentaire que les génériques peuvent aussi avoir un jeu. D'après mes tests, il semble y avoir un impact minimal sur les performances, mais pas assez élevé pour être sûr - les temps de compilation peuvent être incohérents en raison de l'activité du disque. En raison des limites de temps, mes tests n'incluaient pas autant de génériques, ou autant de code, que cela apparaîtrait dans le système en direct, de sorte que 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