Temps de compilation très lents sur Visual Studio 2005

132

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.

johnc
la source
Wow, je pensais que les temps de compilation de 20 secondes étaient extrêmement longs.
Jared Updike
Essayez de proposer plusieurs solutions si possible, car la refactorisation devient beaucoup plus difficile.
Ian Ringrose
Vous pouvez utiliser VSS en dehors de visual-studio de cette façon, vous n'obtenez pas la surcharge de visual-studio parler à VSS.
Ian Ringrose
Et les ressources? J'imagine qu'ils ralentissent le processus. J'ai vu des logiciels commerciaux avec des fichiers exe de la taille d'un CD que vous démarrez à partir du CD (pas de configuration). Ils étaient pleins de vidéos, d'audio et d'images. Donc, le logiciel était juste ce fichier ...
Bitterblue

Réponses:

74

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.
Nate
la source
30
Par désactiver la mémoire virtuelle, je suppose que vous entendez désactiver le swap, la désactivation de la mémoire virtuelle nécessiterait une réécriture de l'ensemble du système d'exploitation; p
Joseph Garvin
9
Cela ressemble à une réponse destinée aux builds C ++ et non aux builds C #
Ian Ringrose
2
Vous avez raison! Bien que je doive souligner que j'ai répondu avant qu'il ne spécifie C #, et certains des correctifs s'appliquent toujours.
Nate
* Stocker le projet sur un disque SSD * Désactiver l'indexation de Windows (dans un gestionnaire de fichiers, clic droit sur le dossier solution, Propriétés-> Avancé, décochez la case "Autoriser les fichiers ... indexés ...")
nos
+1 Si vous avez assez de RAM, gardez le projet sur le disque RAM. Il peut améliorer considérablement les performances jusqu'à 50-70%. Vérifiez codeproject.com/Articles/197663/Speed-up-Visual-Studio-Builds pour plus d'informations
Arjun Vachhani
58

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

terminé à 4 tours
la source
2
Également utilisé cette technique, avec une solution ayant 180 projets. Cela a beaucoup aidé. Vous pouvez même utiliser la ligne de commande pour construire la solution entière `devenv.exe / build yoursolution / takealookatthedoc`` ... de sorte que vous travaillez avec seulement quelques projets, et si nécessaire, vous recompilez la solution entière dans une ligne cmd (après un obtenir la dernière version par exemple)
Steve B
Avez-vous des liens qui décrivent comment cela se fait? Je ne veux pas dire écrire un plugin VS. Plutôt, les tâches spécifiques décrites
Daniel Dyson
@Daniel Dyson: À quel point avez-vous besoin de savoir? Tout se résume à 1) charger tous les projets déchargés 2) itérer la hiérarchie solution / projet / référence 3) trouver des projets avec des références à d'autres projets 4) changer les références «choisies» aux références DLL (avec des chemins d'indication corrects) puis 5) déchargement des projets indésirables. «Choisi» se fait soit via le menu de contenu (c'est-à-dire le (s) projet (s) sélectionné (s)) ou via une arborescence de cases à cocher pour sélectionner des éléments.
Fini le codage le
Merci. Cela devrait suffire à me lancer.
Daniel Dyson
1
@HiTechMagic Ah, désolé d'entendre ça. Mais oui, le publier en open source signifie que nous pouvons tous aider. Veuillez poster le lien github ici si vous le libérez.
georgiosd
24

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.

Kim
la source
4
Comment un SSD se comparerait-il au rapace. Encore plus rapide i gues
RvdK
4
Ouaip. Mon ordinateur portable avec un Intel X25M est plus rapide dans tous les aspects que mon ordinateur de bureau avec un WD Raptor.
CAD bloke le
4
Cela peut sembler surprenant, mais il ne vaut actuellement pas la peine d'investir dans un lecteur à 10000 tr / min. La raison en est que les meilleurs disques à 7200 tr / min sont plus rapides sur le bord extérieur. Donc, ce qu'il faut faire est de créer une petite partition. La première partition est sur le bord extérieur, cette partition sera plus rapide qu'un lecteur à 7200 tr / min, et vous avez encore de l'espace pour une deuxième grande partition sur laquelle stocker des choses.
darklon
2
@cornelius: puis-je obtenir un lien qui élabore votre point? La seule façon dont la jante extérieure d'un 7200 pourrait être plus rapide que la jante extérieure d'un 10000 serait si les 7200 avaient tendance à avoir un rayon, ce qui pourrait peut-être être, mais vraiment cette astuce serait une sorte de piratage et ne fournirait aucun avantage. pour le reste du stockage du disque dur sur le 7200 qui est en dessous du rayon d'équilibre auquel les deux disques ont une vitesse tangentielle égale.
eremzeit
2
Je suis avec CADbloke. Nous avons utilisé des rapaces jusqu'à l'année dernière lorsque le prix des SSD a baissé au point que nous n'utilisons que des SSD pour les disques principaux de nos ordinateurs portables / ordinateurs de bureau. L'augmentation de la vitesse est fantastique et est facilement le facteur le plus important du temps nécessaire à la compilation de nos solutions.
NotMe
16

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

Alex Davies
la source
N'est-ce pas ce que VS fait déjà? Ou vous voulez dire que les modifications non pertinentes telles que les commentaires, etc. sont supprimées?
nawfal
1
Redgate a malheureusement arrêté le travail sur .net demon, il ne fonctionne donc pas au-dessus de VS 2013
Robert Ivanc
14

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

jdelator
la source
2
... pour le dossier code / compile. Faire de la protection audiovisuelle une règle de couverture globale n'est pas une idée brillante. : o)
Brett Rigby
5
Vous n'avez pas vraiment besoin de le désactiver, il suffit généralement de le configurer correctement. Ajoutez des exceptions aux types de fichiers avec lesquels le compilateur / éditeur de liens fonctionne. Certains packages antivirus ont ces exceptions ajoutées par défaut, d'autres non.
darklon
@cornelius Quelle est la bonne configuration antivirus? Pouvez-vous fournir des détails? (peut-être dans une question distincte?)
Pavel Radzivilovsky
@Pavel: Eh bien, excluez les types de fichiers avec lesquels le compilateur fonctionne, pour C ++, ce serait des choses comme .o, .pdb, .ilk, .lib, .cpp, .h. En outre, certains logiciels antivirus (par exemple, Avira AntiVir) vous permettent de définir l'analyse des fichiers en lecture, en écriture ou les deux. Le paramétrer pour scanner à la lecture vous offrira une protection de 99%.
darklon
12

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.

aku
la source
L'installation d'IncrediBuild sur plusieurs PC de rechange a réduit le temps de compilation d'un facteur 10 ou plus pour notre projet C ++ avec presque aucun effort d'administration.
Stiefel
a eu la même expérience aku ... mais le lien était toujours un problème hehe
Paul Carroll
Si vous suivez cette voie, le simple fait d'avoir quelques serveurs de construction dédiés fonctionnerait. Cependant, il semble que l'OP essayait de corriger les temps de compilation sur les machines de développement locales.
NotMe
11

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.

Sean
la source
8

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.

Kristopher Johnson
la source
Si les en-têtes pré-compilés fonctionnent pour vous, c'est une bonne astuce, mais ils ne fonctionnent que si vous pouvez établir un sous-ensemble commun d'en-têtes qui change rarement. Si vous continuez à avoir à précompiler les en-têtes la plupart du temps que vous créez, vous n'enregistrez rien.
Tom Swirly
7

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

Hace
la source
7

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

GeekyMonkey
la source
Pouvez-vous expliquer pourquoi c'est plus rapide? "Références de projet" implique la construction de projet (qui est beaucoup plus lente qu'une référence DLL directe).
Fini le codage
6

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.

Ed S.
la source
1
Faites attention. Il y a un bogue en 2008 qui tronque les builds. MS disent qu'ils ne résoudront pas avant vs2010. C'est un problème terrible car il tronque les fichiers .obj provoquant des problèmes de build confus persistants. Tu étais prévenu. ;) social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/…
Justin
6

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:

Thomas K
la source
5

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.

Pavel Radzivilovsky
la source
5

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.

Jonathan
la source
D'après mon expérience, les disques RAM n'aident pas les temps de construction de VS, et ils sont pénibles car vous devez les recréer chaque fois que votre ordinateur redémarre ou plante. Voir l'article de blog ici: josephfluckiger.blogspot.com/2009/02/…
BrokeMyLegBiking
3

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.

Weeble
la source
J'ai quitté l'emploi que c'était un problème il y a quelque temps, mais dans mon nouveau poste, c'est exactement ce que nous avons mis en œuvre! À votre santé. JC
johnc
2

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.

Adam Pierce
la source
La DLL (et ses différents cousins ​​aiment les bibliothèques partagées) est presque toujours une mauvaise idée pour un développeur d'applications aujourd'hui. Les exécutables sont petits, même si vous liez dans chaque dernière bibliothèque que vous utilisez et la quantité de mémoire que vous économisez en partageant le code est également petite. Les DLL remontent à l'époque où l'empreinte du code de programme en mémoire et sur le disque était d'une importance capitale, mais la taille des données, de la mémoire et du disque a augmenté beaucoup plus rapidement que la taille des programmes.
Tom Swirly
2

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

Shog9
la source
Nous pouvons certainement désactiver l'intégration à VSS et la piloter via l'interface utilisateur Source Safe. Belle pensée
Johnc
2

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

David L. Morris
la source
2

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)

GeekyMonkey
la source
1

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

Daniel Auger
la source
1

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

Bramha Ghosh
la source
1
Si tel était le cas, la solution ne serait jamais compilée.
Michael
@Michael il compilera si vous référencez les DLL dans le répertoire de débogage, au lieu d'utiliser des références de projet.
Caleb Jares
1

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.

Mark
la source
1

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.

Chris O
la source
1

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.

JBRWilkinson
la source
La vitesse de
conduite
Pas configuré de manière optimale. 2 Go de RAM, c'est bien trop peu pour commencer.
TomTom le
1

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.

Pavel Radzivilovsky
la source
1

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

Darklon
la source
1

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?

hautain
la source
J'ai aussi eu ce problème avec VS2005 - définitivement pagination
johnc
1

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.

Eric Aho
la source
0

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

Logan
la source
Il doit y avoir un autre problème là-bas, 2 projets devraient bien fonctionner sur une machine décente
johnc
0

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

johnc
la source