Très lent temps de compilation sur Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

Question

Nous sommes très lent temps de compilation, ce qui peut prendre plus de 20 minutes sur les dual core 2 ghz, 2G de Ram des machines.

Beaucoup de cela est dû à la taille de notre solution qui a augmenté de plus de 70 projets, ainsi que VSS qui est un goulot de bouteille en elle-même lorsque vous avez beaucoup de fichiers.(changeant de VSS n'est pas une option, malheureusement, donc je ne veux pas de cela pour descendre dans un VSS bash)

Nous sommes à la recherche à la fusion des projets.Nous sommes également à la recherche d'avoir de multiples solutions pour parvenir à une plus grande séparation des préoccupations et plus rapide temps de compilation pour chaque élément de l'application.Ce que je peux voir, va devenir l'enfer des DLL que nous essayons de garder les choses dans synch.

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

Mise à JOUR J'ai oublié de mentionner c'est une solution C#.Merci à tous pour le C++ suggestions, mais il a été quelques années depuis que je ai eu à se soucier d'en-têtes.

EDIT:

Nice suggestions qui ont aidé à ce jour (ne pas qu'il n'y a pas d'autres excellentes suggestions ci-dessous, tout ce qui a aidé)

Nouvelle 3 ghz ordinateur portable - le pouvoir de la perte de l'utilisation des œuvres des merveilles quand whinging de gestion
Désactiver l'Anti Virus lors de la compilation
'Déconnexion' à partir de VSS (en fait le réseau) lors de la compilation j'ai peut nous amener à supprimer VS-intégration de VSS complètement et de se tenir à l'utilisation de la VSS de l'INTERFACE utilisateur

Toujours pas de rip-renifler par le biais de la compilation, mais chaque petit geste compte.

Orion a mentionné dans un commentaire que les génériques peuvent avoir un jeu aussi.De mes tests, il ne semble pas y avoir un minimum de performances, mais pas assez élevée pour assurer - les temps de compilation peut être irrégulière en raison du disque de l'activité.En raison de contraintes de temps, mes tests ne comprend pas que de nombreux Génériques, ou plus de code, comme il apparaît dans le système live, donc, qui peuvent s'accumuler.Je ne voudrais pas éviter l'utilisation de génériques où ils sont censés être utilisé, juste pour le moment de la compilation de la performance

Solution de CONTOURNEMENT

Nous testons la pratique de la construction de nouvelles zones de l'application de nouvelles solutions, de l'importation dans le dernier dll requis, eux, leur intégration dans la plus grande solution quand nous sommes heureux avec eux.

Nous pouvons également faire de même pour le code existant par la création de solutions temporaires qui vient d'encapsuler les domaines nous devons travailler sur, et de les jeter après la réintégration du code.Nous avons besoin de peser le temps qu'il faudra pour réintégrer le présent code contre le temps de nous gagner à ne pas avoir de Rip Van Winkle, comme des expériences avec rapide recompiler au cours du développement.

La solution

L'Chromium.org l'équipe de la liste de plusieurs options pour l'accélération de la construction (à ce stade, environ à mi-chemin en bas de la page):

Dans l'ordre décroissant de speedup:

Installer le correctif Microsoft 935225.

Installer le correctif Microsoft 947315.

L'utilisation d'un vrai processeur multicœur (ie.un processeur Intel Core Duo 2;pas un Pentium 4 HT).

Utiliser 3 des constructions parallèles.Dans Visual Studio 2005, vous trouverez l'option en Outils > Options...> Les projets et les Solutions > Construire et Exécuter > nombre maximum de parallèles projet s'appuie.

Désactiver votre logiciel anti-virus pour .ilk, .pdb, .cc, .h fichiers et seulement vérifier la présence de virus sur modifier.Désactiver l'analyse du répertoire où vos sources de résidence.Ne pas faire de bêtises.

De stocker et de construire le Chrome code sur un deuxième disque dur.Il ne sera pas vraiment accélérer le construire, mais au moins, votre ordinateur va rester réactif lorsque vous ne gclient de synchronisation ou d'une construction.

Défragmenter votre disque dur régulièrement.

Désactiver la mémoire virtuelle.

Autres conseils

Nous avons près de 100 projets dans une solution et un dev moment de la construction de seulement quelques secondes :)

Pour le développement local s'appuie, nous avons créé un Visual Studio add-in qui change Project references pour DLL references et de décharge de la non désirés projets (et une option permettant de basculer en arrière, bien sûr).

Construire l'ensemble de notre solution une fois
Décharger les projets que nous ne sommes pas en train de travailler sur et de modifier toutes les références de projet à la DLL références.
Avant le check-in changer toutes les références à partir d'une DLL pour les références de projet.

Notre construit maintenant que prendre quelques secondes lorsque l'on travaille sur quelques projets à la fois.Nous pouvons également toujours effectuer le débogage des projets supplémentaires car elle est reliée à la Dll de débogage.L'outil prend en général de 10 à 30 secondes pour faire un grand nombre de changements, mais vous n'avez pas à le faire souvent.

Mise À Jour Mai 2015

Le deal que j'ai fait (dans les commentaires ci-dessous), était que je relâchez le plugin Open Source si il obtient suffisamment d'intérêt.4 ans plus tard, il a seulement 44 votes (et Visual Studio a maintenant deux versions ultérieures), de sorte qu'il est actuellement une priorité faible du projet.

J'ai eu un problème similaire sur une solution avec 21 projets et 1/2 millions de LOC.La plus grande différence a été plus rapide des disques durs.À partir de l'analyseur de performances de la " Moy.File d'attente du disque' serait de sauter de manière significative sur l'ordinateur portable indiquant que le disque dur a été le goulot de la bouteille.

Voici quelques données pour le total des temps de reconstruction...

1) ordinateur Portable Core 2 Duo 2 ghz, 5400 TR / min en Voiture (pas sûr de cache.Standard Dell inspiron).

Le Temps de reconstruction = 112 secondes.

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

Le Temps de reconstruction = 72 secondes.

3) ordinateur de Bureau Core 2 Duo 3Ghz, seul 10000 TR / min WD Raptor

Le Temps de reconstruction = 39 secondes.

Les 10 000 TR / min en voiture ne peut pas être sous-estimée.Construit où significativement plus rapide, plus tout le reste comme l'affichage de la documentation, à l'aide de l'explorateur de fichiers a été perceptible plus rapide.Il était d'une grande augmentation de la productivité en accélérant le code-compilation-exécution du cycle.

Compte tenu de ce que les entreprises dépensent sur le développeur de salaires qu'il est fou combien ils peuvent déchets d'acheter de l'équipement avec le même Pc que le réceptionniste utilise.

Pour C# .NET construit, vous pouvez utiliser .NET Démon.C'est un produit qui prend en charge Visual Studio construire des processus afin de le rendre plus rapide.

Il le fait en analysant les changements que vous avez faits, et ne construit que le projet vous a réellement changé, ainsi que d'autres projets qui s'appuient effectivement sur les modifications que vous avez apportées.Cela signifie que si vous modifiez uniquement le code interne, un seul projet a besoin de construire.

Désactiver votre antivirus.Il ajoute de l'âge au moment de la compilation.

Utiliser une compilation distribuée.Xoreax IncrediBuild peut couper le temps de compilation vers le bas pour quelques minutes.

Je l'ai utilisé sur un énorme C\C++ solution qui prend généralement 5 à 6 heures à compiler.IncrediBuild contribué à réduire ce délai à 15 minutes.

Instructions pour réduire votre Visual Studio compiler le temps de quelques secondes

Visual Studio est malheureusement pas assez intelligent pour distinguer l'un de l'assemblée des modifications de l'interface de sans conséquence code les changements du corps.De ce fait, lorsqu'il est combiné avec un grand entrelacés des solutions, peut parfois créer une tempête parfaite de la les "full-construit" presque à chaque fois que vous modifiez une seule ligne de code.

Une stratégie pour surmonter ce problème est de désactiver la référence automatique-arbre construit.Pour ce faire, utiliser le "Gestionnaire de Configuration" (Construire / Gestionnaire de Configuration...puis dans la configuration de la solution Active déroulante, choisissez "Nouveau") pour créer une nouvelle configuration de la compilation appelée "ManualCompile' que des copies de la configuration de Débogage, mais ne pas cocher la case "Créer de nouvelles configurations de projet de la case".Dans cette nouvelle configuration de build, décochez chaque projet de sorte qu'aucun d'entre eux va construire automatiquement.Enregistrer cette configuration en appuyant sur 'Fermer'.Cette nouvelle configuration de build est ajouté à votre fichier de solution.

Vous pouvez passer d'une configuration à l'autre via la configuration de build menu déroulant en haut de votre IDE de l'écran (celui qui montre généralement soit "Debug" ou "Release").Effectivement cette nouvelle ManualCompile de configuration de la compilation rendra inutile le menu générer des options pour:'Générer la Solution" ou "Reconstruire la Solution".Ainsi, lorsque vous êtes dans le ManualCompile mode, vous devez créer manuellement chaque projet que vous êtes en train de modifier, qui peut être fait par un clic droit sur chaque projet dans l'Explorateur de solutions, puis en sélectionnant 'Construire' ou de 'Reconstruction'.Vous devriez voir que l'ensemble de votre temps de compilation sera désormais en quelques secondes.

Pour que cette stratégie fonctionne, il est nécessaire pour la VersionNumber trouvé dans les AssemblyInfo et GlobalAssemblyInfo fichiers de rester statique sur le développeur de la machine (pas au cours de la libération s'appuie bien sûr), et que vous ne signez pas votre Dll.

Un risque potentiel de l'utilisation de ce ManualCompile stratégie est que le développeur peut oublier de compiler des projets requis, et quand ils commencent le débogueur, ils obtiennent des résultats inattendus (impossible d'attacher le débogueur, les fichiers non trouvés, etc.).Pour éviter cela, il est probablement préférable d'utiliser le 'Debug' configuration de la compilation pour compiler un plus grand effort de codage, et d'utiliser uniquement la ManualCompile de configuration de la compilation lors de tests unitaires ou pour faire des changements rapides qui sont de portée limitée.

Si c'est le C ou C++, et que vous n'êtes pas en utilisant les en-têtes précompilés, vous devriez être.

Nous avons eu une 80+ projets dans notre principale solution qui a pris environ 4 à 6 minutes de bâtir selon le type de machine, un promoteur a été de travail.Nous avons considéré que, pour être trop long:pour chaque test il vraiment ronge votre Etp.

Donc comment obtenir plus rapidement les temps de construire?Comme vous semblez sais déjà que c'est le nombre de projets qui ont vraiment du mal à la compilation.Bien sûr nous n'avons pas envie de se débarrasser de tous nos projets et de simplement jeter tous les sourcefiles en un seul.Mais nous avons eu quelques projets que nous pourrions combiner néanmoins:Comme chaque Référentiel "projet" dans la solution de ses propres unittest projet, nous avons simplement combiné tous les unittest projets en un mondiaux-unittest projet.Qui ont réduit le nombre de projets avec près de 12 projets et en quelque sorte enregistré 40% du temps pour construire l'ensemble de la solution.

Nous réfléchissons à une autre solution si.

Avez-vous également essayé la configuration d'une nouvelle (deuxième) solution avec un nouveau projet?Cette deuxième solution doit simplement intègre tous les fichiers à l'aide de la solution de dossiers.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 en prenant en considération.Les développeurs auraient peut-être tendance à en fait -travail - dans la deuxième solution et négligent complètement la première.Comme la première solution avec le 70+ projets sera la solution qui prend soin de votre objet de la hiérarchie, ce devrait être la solution où votre buildserver doit exécuter tous vos unittests.Si le serveur pour l'Intégration Continue doit être le premier projet/solution.Vous devez maintenir votre objet de la hiérarchie, à droite.

La deuxième solution avec un seul projet (qui sera la construction d'mucho plus rapide) sera le projet où de test et de débogage sera fait par tous les développeurs.Vous devez prendre soin d'eux en regardant le buildserver si!Si quelque chose se casse, elle DOIT être fixe.

Assurez-vous que vos références sont références de Projet, et non pas directement à la Dll dans la bibliothèque de la sortie des répertoires.

Aussi, ces configuré pour ne pas copier localement, sauf en cas d'absolue nécessité (Le maître EXE du projet).

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 le compiler à l'aide de la /MP drapeau de construire un 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 créer plusieurs projets en parallèle en utilisant le /M drapeau, mais ce n'est déjà définie pour le nombre de cœurs disponibles sur la machine, mais cela s'applique uniquement aux 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 que peu de moi ces derniers temps, et les deux choses que l'amélioration de la génération de performance le plus étaient (1) l'utilisation d'un dédié (et rapide) de disque pour la compilation et (2) utiliser le même outputfolder pour tous les projets, et de définir CopyLocal à Faux sur les références de projet.

Quelques ressources supplémentaires:

Certains outils d'analyse:

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

Ajouter /Bt commutateur de ligne de commande du compilateur pour voir combien chaque fichier CPP a pris

Utilisation /showIncludes pour attraper imbriqués inclut (fichiers d'en-tête d'inclure d'autres fichiers d'en-tête), et de voir quels fichiers peuvent économiser beaucoup de IO par l'aide de sa déclaration.

Cela vous aidera à optimiser le compilateur les performances en éliminant les dépendances et les performances des porcs.

Avant de dépenser de l'argent pour investir dans des disques dur plus rapides, essayez de construire votre projet sur un disque RAM (en supposant que vous avez la mémoire vive de rechange).Vous pouvez trouver différents libérer de la mémoire vive disque drivers sur le net.Vous ne trouverez pas de lecteur physique, y compris les disques Ssd, qui sont plus rapides qu'un disque RAM.

Dans mon cas, un projet qui a pris 5 minutes pour construire sur un 6-core i7 sur un 7200 TR / min SATA lecteur avec Incredibuild a été réduit que de 15 secondes à l'aide d'un disque RAM.Considérant la nécessité de les recopier dans le stockage permanent et le potentiel pour le travail perdu, 15 secondes n'est pas suffisamment de motivation pour utiliser un disque RAM et probablement pas beaucoup d'intérêt à dépenser plusieurs centaines de dollars sur un haut-TR / min ou SSD.

Le gain peut indiquer que la construction était en CPU, ou que Windows fichier de mise en cache a été plutôt efficace, mais depuis les deux tests ont été fait à partir d'un état où les fichiers n'ont pas mis en cache, je penche fortement vers le CPU compile.

Selon le code réel vous êtes de la compilation de votre kilométrage peut varier -- alors n'hésitez pas à tester.

Quelle est la taille de votre répertoire de construction, après avoir fait un build complet?Si vous vous en tenez à la configuration par défaut, puis chaque assemblée que vous générez permet de copier tous les Dll de ses dépendances et de ses dépendances les dépendances etc.à son répertoire bin.Dans mon précédent emploi lorsque vous travaillez avec une solution de ~40 projets de mes collègues ont découvert que, de loin, la partie la plus coûteuse du processus de construction a été la copie de ces assemblées et que l'on pourrait construire générer des giga-octets de copies de la même Dll, encore et encore.

Voici quelques conseils utiles à partir de Patrick Smacchia, auteur de NDepend, à propos de ce qu'il croit doit et ne doit pas être assemblées distinctes:

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

Il existe essentiellement deux façons de contourner cela, et les deux ont des inconvénients.L'un est de réduire le nombre d'assemblages, ce qui est évidemment beaucoup de travail.Une autre est de restructurer vos répertoires de construction, de sorte que tous vos bin dossiers sont consolidés et les projets ne pas faire de copier leurs dépendances " Dll - ils n'ont pas besoin parce qu'ils sont tous dans le même répertoire.Cela réduit considérablement le nombre de fichiers créés et copié lors d'une compilation, mais il peut être difficile à configurer et peut vous laisser avec une certaine difficulté tirant seulement les fichiers Dll requis par un exécutable spécifique pour l'emballage.

Peut-être prendre en commun certaines fonctions et de faire un certain nombre de bibliothèques, de cette façon, les mêmes sources ne sont pas compilés, encore et encore, pour de multiples projets.

Si vous êtes inquiet sur les différentes versions de Dll, de se mêler, de l'utilisation de bibliothèques statiques.

Désactiver l'intégration de VSS.Vous ne pouvez pas avoir un choix dans l'utilisation des ti, mais de Dll obtenir "accidentellement" a été renommé tout le temps...

Et certainement vérifier votre en-tête précompilé paramètres.Bruce Dawson guide est un peu vieux, mais toujours très bonne - check it out: http://www.cygnus-software.com/papers/precompiledheaders.html

J'ai un projet qui est de 120 ou plus exe, libs et les dll et prend beaucoup de temps à construire.J'utilise une arborescence de fichiers batch que des appels de fichiers à partir d'un mélange-maître du fichier.J'ai eu des problèmes avec des choses bizarres à partir de incrémentale (ou était-ce tempérament) des en-têtes dans le passé, donc j'évite maintenant.Je fais plein de construire rarement, et laissent généralement à la fin de la journée alors que je aller pour une promenade d'une heure (donc je ne peux que deviner, il faut environ une demi-heure).Donc, je comprends pourquoi c'est impraticable pour le travail et les tests.

De travail et de tests, j'ai une série de fichiers de commandes pour chaque application (ou d'un module ou de la bibliothèque) qui ont également tous les paramètres de débogage en place -- mais il reste encore à appeler le même rendre les fichiers.J'ai peut-commutateur de DÉBOGAGE sur de off de temps en temps et aussi décider construit ou fait, ou si je veux aussi construire des libs que le module peut dépendre, et ainsi de suite.

Le fichier de commandes copie également le formulaire de résultat dans le (ou plusieurs) test de dossiers.En fonction des paramètres de ce termine dans quelques secondes à une minute (par opposition à-dire une demi-heure).

J'ai utilisé un autre IDE (Zeus), comme j'aime avoir le contrôle sur des choses comme .fichiers rc, et préfèrent les compiler à partir de la ligne de commande, même si je suis à l'aide de MS cas de déviation.

Heureux de publier un exemple de ce fichier de commandes 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)

Si c'est une application web, réglage lot construire de véritable peut aider, selon le 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 vouloir vérifier la circulaire références de projet.Il a été un problème pour moi une fois.

C'est:

Projet Un Projet fait référence à B

Le projet B Projet fait référence à C

Le projet C Projet fait référence à Un

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

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

Puis, vous devez compiler le uber des unités plutôt que des modules individuels.Nous avons vu les temps de compilation à partir de 10-15 minutes en bas à 1-2 minutes.Vous pourriez avoir à experiemnt avec combien d' #comprend par uber fichier de sens.Dépend des projets.etc.Peut-être que vous incluez 10 fichiers, peut-être 20.

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

Vous ne pouvez pas cliquez-droit sur un fichier et de dire "compiler..." que vous avez à exclure la personne du rpc fichiers à partir de la génération et ne comprennent que les uber fichiers cpp
Vous devez être prudent de variable globale statique des conflits.
Lorsque vous ajoutez de nouveaux modules, vous devez garder à l'uber à jour les fichiers

C'est une sorte de douleur, mais pour un projet qui est en grande partie statique en termes de nouveaux modules, de l'initiale de la douleur pourrait être en vaut la peine.J'ai vu cette méthode battre de l'IB dans certains cas.

Si c'est un projet C++, alors vous devriez être en utilisant les 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 est vraiment en train de faire (avec la non utilisation des en-têtes précompilés), il semble être à la recherche pour beaucoup STL-têtes dans tous les mauvais endroits avant d'aller à l'emplacement correct.Cela ajoute un ensemble de secondes à chaque unique .rpc fichier compilé.Vous ne savez pas si c'est un cl.exe bug, ou une sorte de STL problème dans VS2008.

En regardant la machine que vous êtes en train de construire sur, est-il configuré de manière optimale?

Nous venons de construire notre temps pour notre plus grand C++ échelle de l'entreprise, du produit vers le bas à partir de 19 heures pour 16 minutes en assurant le droit SATA pilote de filtre a été installé.

Subtile.

Il y a des sans-papiers commutateur /MP dans Visual Studio 2005, voir http://lahsiv.net/blog/?p=40, ce qui permettrait de compilation parallèle sur le fichier de base plutôt que sur une base de projet.Cela peut accélérer la compilation de ce dernier projet, ou, si vous compilez un projet.

Lors du choix d'un PROCESSEUR:Taille du cache L1 semble avoir un énorme impact sur le temps de compilation.Aussi, il est généralement préférable d'avoir 2 cœurs rapides que 4 lentes.Visual Studio n'est pas possible d'utiliser les très cœurs de manière très efficace.(Je me base sur mon expérience avec le compilateur C++, mais il est probablement vrai aussi pour le C# un.)

Je suis aussi maintenant convaincu qu'il y a un problème avec VS2008.Je suis en cours d'exécution sur un dual core Intel ordinateur portable avec la 3G de Ram, avec l'anti-virus désactivé.La compilation de la solution est souvent assez lisse, mais si j'ai été le débogage d'une ultérieure recompiler souvent ralentir à une exploration.Il est clair à partir de l'continue disque principal de la lumière qu'il ya un disque I/O goulot d'étranglement (vous pouvez l'entendre, trop).Si j'annule la construction et de l'arrêt de VS l'activité du disque s'arrête.Redémarrez VS, recharger la solution, puis à reconstruire, et il est beaucoup plus rapide.Jusqu'à la prochaine fois

Mes pensées sont que c'est un problème de pagination de la mémoire - VS juste à court de mémoire et de l'O/S commence l'échange de la page pour essayer de faire de la place mais VS demande de plus que l'échange de la page peut offrir, donc il ralentit considérablement.Je ne vois pas d'autre explication.

VS n'est certainement pas un RAD de l'outil, est-il?

Est-ce que votre entreprise utilise Confient pour leur PKI/solution de Chiffrement par hasard?Il s'avère, nous avions insondable génération de performance pour un assez grand site web construit en C#, 7 minutes sur une Reconstruction-Tous.

Ma machine est un i7-3770 avec 16 go de ram et un disque SSD de 512 go, de sorte que les performances ne doivent pas avoir été si mauvais que ça.J'ai remarqué que mon temps de construire ont été incroyablement plus rapide sur une ancienne machine secondaire bâtiment de la même base de code.Donc j'ai tiré jusqu'ProcMon sur les deux machines, présenté le construit, et comparé les résultats.

Lo et voici, l'exécution lente de la machine a une différence, une référence à la Entrust.dll dans le stacktrace.En utilisant ce nouvel acquis info, j'ai continué à rechercher StackOverflow et trouvé ceci: MSBUILD (VS2010) très lent sur certaines machines.Selon la accepté de répondre, le problème réside dans le fait de le Confier gestionnaire de traitement de l' .NET les vérifications de certificats au lieu de la native de Microsoft gestionnaire.Tt est également proposé de Confier v10 permet de résoudre ce problème qui est très répandue dans l'Confier 9.

Actuellement, je l'ai désinstallé et mon temps de construire a chuté à 24 secondes.YYMV avec le nombre de projets en cours de construction et ne peut pas traiter directement le problème d'évolutivité vous étiez renseigner à son sujet.Je vais poster une modification à cette réponse, si je peux fournir un correctif sans le recours à la 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 fait c'est pour installer VS2008 pour la mise à jour de mon projet qui a été créé avec VS2005.Je n'ai que 2 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')

Nouvelle 3 ghz ordinateur portable - le pouvoir de la perte de l'utilisation des œuvres des merveilles quand whinging de gestion
Désactiver l'Anti Virus lors de la compilation
'Déconnexion' à partir de VSS (en fait le réseau) lors de la compilation j'ai peut nous amener à supprimer VS-intégration de VSS complètement et de se tenir à l'utilisation de la VSS de l'INTERFACE utilisateur

Toujours pas de rip-renifler par le biais de la compilation, mais chaque petit geste compte.

Nous sommes également en train de tester la pratique de la construction de nouvelles zones de l'application de nouvelles solutions, de l'importation dans le dernier dll requis, eux, leur intégration dans la plus grande solution quand nous sommes heureux avec eux.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow