Sehr langsame Kompilierungszeiten in Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

Frage

Wir bekommen sehr langsame Kompilierungszeiten, die auf Dual-Core-2GHz- und 2G-Ram-Maschinen mehr als 20 Minuten dauern können.

Dies liegt zum großen Teil an der Größe unserer Lösung, die mittlerweile auf über 70 Projekte angewachsen ist, sowie an VSS, das bei vielen Dateien einen Flaschenhals darstellt.(Der Austausch von VSS ist leider keine Option, daher möchte ich nicht, dass dies zu einem VSS-Bash wird.)

Wir prüfen die Zusammenlegung von Projekten.Wir suchen auch nach mehreren Lösungen, um eine bessere Trennung der Belange und schnellere Kompilierungszeiten für jedes Element der Anwendung zu erreichen.Ich kann mir vorstellen, dass dies zur DLL-Hölle werden wird, wenn wir versuchen, die Dinge synchron zu halten.

Mich interessiert, wie andere Teams mit diesem Skalierungsproblem umgegangen sind. Was tun Sie, wenn Ihre Codebasis eine kritische Masse erreicht, sodass Sie den halben Tag damit verschwenden, zuzusehen, wie die Statusleiste Kompiliermeldungen liefert?

AKTUALISIERENIch habe vergessen zu erwähnen, dass es sich um eine C#-Lösung handelt.Vielen Dank für alle C++-Vorschläge, aber es ist schon ein paar Jahre her, dass ich mir Sorgen um Header machen musste.

BEARBEITEN:

Schöne Vorschläge, die bisher geholfen haben (ich sage nicht, dass es unten keine anderen netten Vorschläge gibt, sondern nur, was geholfen hat)

Neuer 3-GHz-Laptop – die Leistung der verlorenen Auslastung wirkt Wunder, wenn es ums Management geht
Deaktivieren Sie Antivirus während der Kompilierung
„Trennen“ der Verbindung zu VSS (eigentlich dem Netzwerk) während der Kompilierung – ich kann uns möglicherweise dazu veranlassen, die VS-VSS-Integration ganz zu entfernen und bei der Verwendung der VSS-Benutzeroberfläche zu bleiben

Immer noch kein rasantes Kompilieren, aber jedes bisschen hilft.

Orion erwähnte in einem Kommentar, dass auch Generika eine Rolle spielen könnten.Bei meinen Tests scheint es einen minimalen Leistungseinbruch zu geben, der jedoch nicht hoch genug ist, um sicher zu sein – die Kompilierungszeiten können aufgrund der Festplattenaktivität inkonsistent sein.Aus zeitlichen Gründen umfassten meine Tests nicht so viele Generics oder so viel Code, wie im Live-System erscheinen würde, sodass sich diese anhäufen können.Ich würde es nicht vermeiden, Generika dort zu verwenden, wo sie verwendet werden sollen, nur aus Gründen der Leistung bei der Kompilierung

Problemumgehung

Wir testen die Praxis, neue Anwendungsbereiche in neuen Lösungen zu erstellen, die neuesten DLLs nach Bedarf zu importieren und sie in die größere Lösung zu integrieren, wenn wir damit zufrieden sind.

Dasselbe können wir auch mit vorhandenem Code machen, indem wir temporäre Lösungen erstellen, die nur die Bereiche einschließen, an denen wir arbeiten müssen, und sie nach der erneuten Integration des Codes wegwerfen.Wir müssen die Zeit abwägen, die für die Reintegration dieses Codes benötigt wird, und die Zeit, die wir gewinnen, wenn wir während der Entwicklung keine Erfahrungen wie Rip Van Winkle mit schneller Neukompilierung machen.

Lösung

Die Chromium.org Team mehrere Optionen aufgelistet für die Build-Beschleunigung (an dieser Stelle etwa auf halbem Weg nach unten auf der Seite):

Um von Speedup abnehmend:


Installieren Sie Microsoft Hotfix 935.225 .

Installieren Sie Microsoft Hotfix 947.315 .

Verwenden Sie einen echten Multi-Core-Prozessor (dh ein Intel Core Duo. 2, kein Pentium 4 HT).

Verwenden Sie 3 parallel baut. In Visual Studio 2005, haben Sie die Möglichkeit in Extras> Optionen ... finden> Projekte und Lösungen> Erstellen und Ausführen> maximale Anzahl parallelen Projektes bauen .

Deaktivieren Sie Ihre Anti-Viren-Software für ILK, PDB, .cc, H-Dateien und prüfen nur auf Viren auf modify . Deaktivieren Sie das Verzeichnis scannen, wo Ihre Quellen befinden. Tun Sie das nicht etwas dumm.

Geschäft und bauen die Chromium-Code auf einer zweiten Festplatte. Es wird nicht wirklich die Build beschleunigen, aber zumindest wird der Computer reagiert, bleiben, wenn Sie gclient Sync oder einen Build zu tun.

Defragmentieren Ihrer Festplatte regelmäßig.

Deaktivieren Sie virtuellen Speicher.

Andere Tipps

Wir haben fast 100 Projekte in einer Lösung und eine dev Bauzeit von nur Sekunden:)

Für die lokale Entwicklung baut wir ein Visual Studio Addin erstellt, die Project references Änderungen an DLL references und leert die unerwünschten Projekte (und eine Option, um sie wieder natürlich wechseln).

Erstellen Sie unsere gesamte Lösung einmal
Unload die Projekte, die wir nicht gerade arbeiten und alle Projekt Verweise auf DLL Verweise ändern.
Vor dem Check-in Veränderung von DLL alle Verweise zurück Referenzen zu projizieren.

Unsere baut jetzt nur noch Sekunden dauern, wenn wir nur ein paar Projekte gleichzeitig arbeiten. Wir können auch debuggen noch die zusätzlichen Projekte, wie es zu dem Debug-DLLs verknüpft. Das Werkzeug dauert in der Regel 10 bis 30 Sekunden, um eine große Anzahl von Änderungen zu machen, aber Sie müssen es nicht so oft.

Update Mai 2015

Der Deal I (in den Kommentaren unten) hergestellt war, dass ich die Plugin freigeben würde Quelle zu öffnen, wenn es genug Interesse bekommt. 4 Jahre später hat sie nur 44 Stimmen (und Visual Studio hat nun zwei aufeinanderfolgende Versionen), so ist es zur Zeit ein niedrige Priorität Projekt.

Ich hatte ein ähnliches Problem an einer Lösung mit 21 Projekten und 1/2 Millionen LOC. Der größte Unterschied war immer schnelle Festplatten. die ‚Avg von der Leistung überwachen. Disk Queue‘würde deutlich auf dem Laptop aufspringen, welche die Festplatte wurde mit dem Flaschenhals.

Hier einige Daten für die Gesamt mal wieder aufzubauen ...

1) Laptop, Core 2 Duo mit 2 GHz, 5400 RPM-Laufwerk (nicht sicher, ob der Cache. War Standard Dell Inspiron).

Rebuild Zeit = 112 Sekunden.

2) Desktop (Standard-Ausgabe), Core 2 Duo 2,3 GHz, Single 7.200 Laufwerk 8 MB Cache.

Rebuild-Zeit = 72 Sekunden.

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

Rebuild-Zeit = 39 Sekunden.

Das 10.000 RPM-Laufwerk kann nicht unterschätzt werden. Baut, wo deutlich schneller und alles andere wie Dokumentation anzeigen, Datei-Explorer verwenden wurde noticable schneller. Es war eine große Steigerung der Produktivität durch den Code-Build-Run-Zyklus beschleunigt.

Nach dem, was Unternehmen geben an Entwickler Gehälter ist es verrückt , wie viel sie kaufen verschwenden können sie mit den gleichen PCs equiping wie der Rezeptionist verwendet.

Für C # .NET baut, können Sie . NET Dämon . Es ist ein Produkt, das über den Visual Studio Build-Prozess dauert es schneller zu machen.

Es tut dies durch die Veränderungen zu analysieren Sie gemacht, und baut nur das Projekt, das Sie eigentlich, wie auch andere Projekte geändert, die auf die Änderungen tatsächlich verlassen Sie gemacht. Das heißt, wenn Sie nur internen Code ändern, nur ein Projekt muss bauen.

Schalten Sie Ihre Antivirus. Es fügt Alter bis zur Kompilierung.

Verwenden Sie verteilte Kompilierung. Xoreax IncrediBuild können Kompilierung bis auf wenige Minuten verkürzt.

Ich habe es auf einer riesigen C \ C ++ Lösung verwendet, die 5-6 Stunden dauert in der Regel zu kompilieren. IncrediBuild half diesmal bis 15 Minuten zu reduzieren.

Anleitung für Visual Studio-Kompilierung auf wenige Sekunden reduzieren

Visual Studio ist leider nicht intelligent genug, um einer Assembly-Schnittstelle ändert sich von belanglosen Code Veränderungen des Körpers zu unterscheiden. Diese Tatsache, wenn sie mit einer großen verschlungenen Lösungen kombiniert werden, kann manchmal einen perfekten Sturm von unerwünschten schaffen ‚Voll baut‘ fast jedes Mal, wenn Sie eine einzige Zeile Code ändern.

Eine Strategie, diese zu überwinden, ist der automatische Referenzbaum baut zu deaktivieren. Dazu verwenden Sie die ‚Configuration Manager‘ (Build / Configuration Manager ... dann in dem Active-Lösung Konfiguration Drop-Down, wählen Sie ‚Neu‘) eine neue Build-Konfiguration namens ‚ManualCompile‘, dass Kopien von der Debug-Konfiguration zu erstellen, aber tun nicht überprüfen Sie die ‚neue Projektkonfigurationen erstellen‘ Kontrollkästchen. In dieser neuen Build-Konfiguration, deaktivieren Sie jedes Projekt, so dass keiner von ihnen automatisch bauen. Speichern Sie diese Konfiguration mit ‚Schließen‘ zu treffen. Diese neue Build-Konfiguration wird zu Ihrer Lösung Datei hinzugefügt.

können Sie wechseln von einer Build-Konfiguration auf einen anderen über das Drop-Down-Build-Konfiguration an der Spitze Ihres IDE-Bildschirm (die, die in der Regel entweder ‚Debug‘ oder ‚Release‘ zeigt). ‚Build-Lösung‘ oder ‚Rebuild-Lösung‘: effektiv diese neue ManualCompile Build-Konfiguration der Build-Menüoptionen nutzlos für rendert. Wenn Sie also in dem ManualCompile-Modus befinden, müssen Sie manuell jedes Projekt erstellen, das Sie ändern, die durch einen Rechtsklick auf jedem betroffenen Projekt im Solution Explorer durchgeführt werden kann, und dann ‚Build‘ oder ‚Rebuild‘ auswählen. Sie sollten sehen, dass nun Ihre gesamte Kompilierung mal weniger Sekunden sein wird.

Für diese Strategie zu arbeiten, ist es notwendig, für die Version in der Assembly und GlobalAssemblyInfo Dateien gefunden auf der Entwickler-Maschine statisch zu bleiben (nicht während der Release-Builds natürlich), und dass Sie nicht unterzeichnen Ihre DLLs.

Ein potenzielles Risiko dieses ManualCompile Strategie ist, dass die Entwickler vergessen könnte erforderlich Projekte zu kompilieren, und wenn sie den Debugger starten, bekommen sie unerwartete Ergebnisse (nicht in der Lage Debugger anhängen, Dateien nicht gefunden, etc.). Um dies zu vermeiden, ist es wahrscheinlich am besten die ‚Debug‘ Build-Konfiguration mit einem größeren Programmieraufwand zu erstellen, und verwenden Sie nur die ManualCompile Build-Konfiguration während der Unit-Tests oder für schnelle Änderungen, die von begrenztem Umfang sind.

Wenn das C oder C ++, und Sie verwenden nicht vorkompilierte Header, sollten Sie sein.

Wir hatten ein 80+ Projekte in unserer Lösung, die etwa 4 bis 6 Minuten nahmen zu bauen abhängig, welche Art von Maschine ein Entwickler arbeitet. Wir dachten, dass viel zu lang sein. Für jeden einzelnen Test es Ihre VZÄ wirklich zerfrisst

So, wie man schneller mal bauen? Wie Sie scheinen zu wissen, bereits es die Anzahl der Projekte, die wirklich die Buildtime verletzt. Natürlich wollen wir alle unsere Projekte nicht bekommen zu befreien und einfach alle Quelldateien in einen werfen. Aber wir hatten einige Projekte, die wir dennoch kombinieren können: Wie jedes „Repository-Projekt“ in der Lösung seiner eigenen Unittest-Projekt hatte, wir alle Projekte Unittest in einem global-Unittest-Projekt einfach kombiniert. Das schnitt die Anzahl der Projekte mit etwa 12 Projekten nach unten und gespeichert irgendwie 40% der Zeit, die gesamte Lösung zu erstellen.

Wir über eine andere Lösung denken though.

Haben Sie auch Setup versucht, eine neue (zweite) Lösung mit einem neuen Projekt? Diese zweite Lösung sollte enthält einfach alle Dateien Lösung Ordner verwenden. Weil Sie werden überrascht sein, die Build-Zeit dieses neuen Lösung mit-nur-ein-Projekt zu sehen.

jedoch mit zwei verschiedenen Lösungen arbeiten, werden einige vorsicht berücksichtigen. Entwickler könnten geneigt sein, um tatsächlich in der zweiten Lösung -work- und vollständig Vernachlässigung die ersten. Da die erste Lösung mit den mehr als 70 Projekten wird die Lösung sein, die Pflege Ihrer Objekt-Hierarchie nimmt, soll dies die Lösung sein, wo Ihre Build sollten alle Ihre Unittests laufen. So ist der Server für Kontinuierliche Integration muss die erste Projekt / Lösung sein. Sie haben Ihre Objekt-Hierarchie zu halten, richtig.

Die zweite Lösung mit nur einem Projekt (die mucho schneller aufbauen wird) wird als das Projekt sein, wo das Testen und Debuggen werden von allen Entwicklern durchgeführt werden. Sie haben von ihnen zu kümmern, obwohl bei der Build suchen! Wenn etwas bricht muss es repariert werden.

Stellen Sie sicher, dass Ihre Referenzen sind Projektreferenzen, und nicht direkt auf den DLLs in den Bibliothek Ausgabeverzeichnissen.

Auch haben diese nicht gesetzt lokal zu kopieren, sofern unbedingt erforderlich (Das Master-EXE-Projekt).

Ich gab diese Antwort ursprünglich hier: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Sie können viele andere hilfreiche Hinweise auf dieser Seite finden.

Wenn Sie Visual Studio 2008 verwenden, können Sie kompilieren den / MP-Flag mit einem einzigen Projekt parallel zu bauen. Ich habe gelesen, dass dies auch eine nicht dokumentierte Funktion in Visual Studio 2005, aber noch nie versucht, mich.

Sie können mehrere Projekte parallel aufzubauen, indem die / M-Flag verwenden, aber dies ist in der Regel bereits auf die Anzahl der verfügbaren Cores auf der Maschine eingestellt, obwohl dies nur für VC gilt ++ glaube ich.

Ich stelle fest, diese Frage im Alter von alt ist, aber das Thema ist auch heute noch von Interesse. Das gleiche Problem hat mich gebissen in letzter Zeit, und die beiden Dinge, die Build-Leistung verbesserte ich die meisten waren (1) verwenden, um eine dedizierte (und schnell) Scheibe zum Kompilieren und (2) den gleichen output für alle Projekte und setzt Copylocal auf False auf Projekt Referenzen.

Einige zusätzliche Informationen:

Einige Analysetools:

Extras-> Optionen-> VC ++ Projekteinstellungen -> Build-Timing = Ja werden Sie sagen, Zeit für jeden vcproj bauen.

/Bt Schalter auf Compiler-Befehlszeile hinzufügen, um zu sehen, wie viel jede CPP-Datei nahm

Mit /showIncludes verschachtelt fangen enthält (Header-Dateien, die andere Header-Dateien), und sehen, welche Dateien viel IO sparen könnte durch die Verwendung zukunfts Erklärungen.

Dies wird Ihnen helfen Compiler Leistung zu optimieren, indem Abhängigkeiten und Performance Schweine zu beseitigen.

Geld, bevor die Ausgaben in schnellen Festplatten zu investieren, versuchen Sie Ihr Projekt baut vollständig auf einem RAM-Disk (vorausgesetzt, Sie den RAM zu ersparen). Sie können verschiedenen freien RAM-Disk-Treiber im Netz finden. Sie werden kein physisches Laufwerk, einschließlich SSDs finden, die schneller sind als ein RAM-Disk.

In meinem Fall ein Projekt, das 5 Minuten nahm mit IncrediBuild auf einem 6-Core-i7 auf ein 7200 RPM SATA-Laufwerk zu bauen, wurde von nur etwa 15 Sekunden reduziert, indem einen RAM-Disk verwenden. In Anbetracht der Notwendigkeit, dauerhafte Speicherung und das Potenzial für verlorene Arbeit erneut zu kopieren, 15 Sekunden mehrere hundert Dollar auf einem High-RPM oder SSD-Laufwerk nicht genug Anreiz eine RAM-Disk zu verwenden, und wahrscheinlich nicht viel Anreiz zu verbringen.

Die kleine Verstärkung kann darauf hindeuten, dass der Build war CPU gebunden oder dass Windows Datei-Caching war ziemlich effektiv, aber da beiden Tests von einem Zustand durchgeführt wurden, wo die Dateien nicht im Cache gespeichert wurden, lehne ich mich stark auf CPU-gebundenen compiliert.

Je nach dem tatsächlichen Code, den Sie Ihre Laufleistung kompilieren variieren -. So zögern Sie nicht, testen

Wie groß ist Ihr Build-Verzeichnis nach einer kompletten Build zu tun? Wenn Sie mit dem Standard-Setup-Stick dann jeder Assembly, die Sie bauen alle DLLs ihre Abhängigkeiten kopieren und seine Abhängigkeiten Abhängigkeiten usw. zu seinem ist. In meinem vorherigen Job, wenn sie mit einer Lösung von ~ 40 Projekten arbeiten meine Kollegen bei weitem der teuerste Teil des Build-Prozesses kopiert wurde diese Baugruppen über und über, und dass man aufbauen könnte erzeugen Gigabyte Kopien der gleichen DLLs über entdeckt, dass und immer wieder.

Hier einige nützliche Ratschläge von Patrick Smacchia, Autor von NDepend, über das, was sollte er glaubt, und nicht getrennte Baugruppen sein sollte:

http: // codebetter .com / patricksmacchia / 2008/12/08 / Ratschläge-on-Partitionierung-Code-through-net-Baugruppen /

Es gibt grundsätzlich zwei Möglichkeiten, wie Sie dieses Problem umgehen können, und beide haben Nachteile. Eine davon ist die Anzahl der Baugruppen zu reduzieren, was offensichtlich eine Menge Arbeit ist. Ein weiterer Grund ist Ihre Build-Verzeichnisse restrukturieren, so dass alle Ihr ist Ordner konsolidiert werden, und Projekte nicht ihre Abhängigkeiten DLLs kopieren - sie nicht brauchen, weil sie bereits alle im selben Verzeichnis befinden. Dies reduziert die Anzahl der Dateien während eines Build erstellt und kopiert, aber es kann schwierig sein, zu installieren und können Sie mit einigen Schwierigkeiten läßt nur den erforderlichen DLLs für die Verpackung von einem bestimmten ausführbaren ziehen.

Vielleicht einige gemeinsame Funktionen übernehmen und einige Bibliotheken machen, auf diese Weise die gleichen Quellen nicht immer und immer wieder für mehrere Projekte erstellt werden.

Wenn Sie sich Sorgen über die verschiedenen Versionen von DLLs sind gemischt zu werden, verwenden Sie statische Bibliotheken.

Schalten Sie VSS-Integration. Sie dürfen keine Wahl bei der Verwendung es, aber DLLs bekommen „versehentlich“ umbenannt ganze Zeit ...

Und auf jeden Fall überprüfen Sie die vorkompilierte Header-Einstellungen. Bruce Dawson Leitfaden ist ein bisschen alt, aber immer noch sehr gut - check it out: http://www.cygnus-software.com/papers/precompiledheaders.html

Ich habe ein Projekt, das 120 oder mehr Ex, Libs und dlls hat und nimmt eine beträchtliche Zeit zu bauen. Ich benutze einen Baum von Batch-Dateien, die Dateien von einem Master-Batch-Datei aufrufen. Ich habe Probleme mit rechten Dingen zugeht von inkrementalen hatte (oder war es temperament) Header in der Vergangenheit ihnen so dass ich jetzt vermeiden. Ich habe eine vollständige Erstellung selten und in der Regel lassen Sie es bis zum Ende des Tages, während ich für einen Spaziergang eine Stunde lang gehen (so kann ich nur raten, es dauert etwa eine halbe Stunde). So verstehe ich, warum das für die Arbeit und Prüfung undurchführbar ist.

Für die Arbeit und Prüfung Ich habe einen anderen Satz von Batch-Dateien für jede App (oder ein Modul oder eine Bibliothek), die auch alle Debug-Einstellungen an der richtigen Stelle - aber diese rufen immer noch die gleichen Dateien machen. Ich kann DEBUG einschalten Off von Zeit zu Zeit und auch entscheiden baut oder macht oder wenn ich will auch Libs bauen, dass das Modul abhängen auf, und so weiter.

Die Batchdatei kopiert auch das fertige Ergebnis in die (oder mehrere) Testordner. Abhängig von den Einstellungen dies in einigen Sekunden bis zu einer Minute abgeschlossen ist (im Gegensatz eine halbe Stunde zu sagen).

habe ich einen anderen IDE (Zeus) als Ich mag wie RC-Dateien der Kontrolle über die Dinge haben, und eigentlich lieber über die Befehlszeile kompilieren, obwohl ich MS compliers verwenden.

Happy ein Beispiel dieser Batch-Datei zu schreiben, wenn jemand interessiert ist.

Deaktivieren Dateisystem Indizierung auf Ihrem Quellverzeichnis (speziell die obj Verzeichnisse, wenn Sie Ihre Quelle durchsuchbare wollen)

Wenn dies ein Web-App ist, batch true baut Einstellung kann je nach Szenario helfen.

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

Sie können eine Übersicht finden Sie hier: http: // weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Sie können sich auch für Rundprojektreferenzen überprüfen möchten. Es war ein Problem für mich einmal.

Das heißt:

Projekt A Referenzen Projekt B

Projekt B Referenzen Projekt C

Projekt C Referenzen Projekt A

Eine billigere Alternative zu Xoreax IB ist die Verwendung von was ich uber-Datei erstellt. Es ist im Grunde eine CPP-Datei, die hat

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

Dann kompilieren Sie die uber Einheiten anstelle der einzelnen Module. Wir haben von 10 bis 15 Minuten bis zu 1-2 Minuten Kompilierung Mal gesehen. Möglicherweise müssen Sie mit experiemnt wie viele #includes pro uber Datei Sinn machen. Abhängig von den Projekten. usw. Vielleicht sind Sie 10 Dateien, vielleicht 20.

Sie zahlen eine Kosten also Vorsicht:

Sie können sich nicht auf eine Datei klicken und sagen: „kompilieren ...“, wie Sie die einzelnen CPP-Dateien aus dem Build ausgeschlossen haben und beinhalten nur die uber CPP-Dateien
Sie müssen vorsichtig von statischen globalen Variablen Konflikte.
Wenn Sie neue Module hinzufügen, müssen Sie auf dem neuesten Stand der Uber-Dateien halten

Es ist eine Art Schmerz, aber für ein Projekt, das in Bezug auf die neuen Module, die intial Schmerz könnte sich lohnen es weitgehend statisch ist. Ich habe diese Methode gesehen IB schlug in einigen Fällen.

Wenn es ein C ++ Projekt, dann sollten Sie vorkompilierte Header verwendet werden. Das macht einen großen Unterschied in der Kompilierung Zeiten. Nicht sicher, was cl.exe wirklich tun (mit nicht vorkompilierte Header verwendet wird), es scheint zu suchen Partien von STL-Header in all den falschen Stellen, bevor sie schließlich an die richtige Stelle gehen. Dies fügt ganze Sekunden jede einzelne CPP-Datei kompiliert wird. Nicht sicher, ob dies ein cl.exe Bug ist, oder irgendeine Art von STL Problem in VS2008.

an der Maschine suchen, das Sie bauen auf, ist es optimal konfiguriert?

Wir haben gerade unsere Build-Zeit für unser größtes C ++ Enterprise-scale Produkt nach unten von 19 Stunden 16 Minuten durch die richtigen SATA-Filtertreiber zu gewährleisten installiert wurden.

Subtle.

Es ist nicht dokumentiert / MP-Schalter in Visual Studio 2005 finden Sie unter http://lahsiv.net/blog /? p = 40 , die parallel Kompilierung auf Dateibasis ermöglichen würde, eher als Projektbasis. Dies kann die Erstellung des letzten Projektes beschleunigen, oder, wenn Sie ein Projekt kompilieren.

Bei der Auswahl einer CPU: L1-Cache-Größe einen enormen Einfluss auf Kompilierung zu haben scheint. Außerdem ist es in der Regel besser 2 schnelle Kerne als 4 Langsamen zu haben. Visual Studio nicht die zusätzlichen Kerne verwendet sehr effektiv. (Ich stütze diese auf meinen Erfahrungen mit dem C ++ Compiler, aber es ist wahrscheinlich auch für die C # ein.)

Ich bin auch jetzt überzeugt, ein Problem mit VS2008 ist. Ich laufe es auf einem Dual-Core-Intel-Laptop mit 3G-Ram, mit Anti-Virus ausgeschaltet. die Lösung Kompilieren ist oft ziemlich glatt, aber wenn ich oft eine nachfolgende recompile worden Debuggen wird zu einem Schleichen verlangsamen. Es ist klar, aus dem Dauerlicht Hauptscheibe, dass es ein Disk-I / O-Engpass ist (man kann es hören, auch). Wenn ich die Build-und Shutdown-VS die Plattenaktivität stoppt abzubrechen. Neustart VS, laden Sie die Lösung und dann wieder aufzubauen, und es ist viel schneller. Unitl das nächste Mal

Meine Gedanken sind, dass dies ein Problem Speicher-Paging ist - VS läuft gerade aus dem Speicher und dem O / S startet Seite Swapping versuchen Raum zu machen, aber VS verlangt mehr als Seite-Swapping liefern kann, so dass es bis auf ein verlangsamt kriechen. Ich kann mich an jeder anderen Erklärung.

VS ist definitiv kein RAD-Tool, es ist?

Gibt es in Ihrem Unternehmen passiert Entrust durch eine Chance für ihre PKI / Verschlüsselungs-Lösung verwenden? Es stellt sich heraus, wir miserabel baut Leistung für eine ziemlich große Website in C # gebaut wurden, die unter 7+ Minuten auf einem Rebuild-All.

Meine Maschine ist ein i7-3770 mit 16gb RAM und einer 512 GB SSD, so Leistung sollte nicht so schlimm gewesen. Ich bemerkte meine Bauzeiten auf einer ältere Sekundär Maschine irrsinnig schneller waren die gleiche Code-Basis zu bauen. So feuerte ich ProcMon auf beiden Maschinen auf, profilierte die Builds, und verglichen die Ergebnisse.

Und siehe da, die langsam ausführende Maschine hatte einen Unterschied - einen Verweis auf die Entrust.dll im Stacktrace. Mit diesen neu erworbenen Informationen, fuhr ich fort Stackoverflow zu suchen und fand dieses: MSBUILD (VS2010 ) sehr langsam auf einige Maschinen. Nach Angaben der akzeptierten Antwort liegt das Problem in der Tatsache, wurde der Entrust-Handler des Zertifikat .NET prüft anstelle des nativen Microsoft-Handler verarbeitet. Tt wird auch vorgeschlagen, dass Entrust v10 dieses Problem löst, die in Entrust 9 vorherrschend ist.

Im Moment habe ich es deinstalliert und meine Bauzeiten sank auf 24 Sekunden . YYMV mit der Anzahl der Projekte, die derzeit Sie bauen und nicht direkt die Skalierung Problem beheben können Sie wurden erkundigt. Ich werde bearbeitet, um diese Antwort hinterlassen, wenn ich ein Update zur Verfügung stellen kann ohne die Software zu einer Deinstallation zurückzugreifen.

Es ist sicher ein Problem mit VS2008 gibt. Denn das einzige, was ich getan habe, ist es VS2008 zu installieren für mein Projekt aktualisieren, die mit VS2005 erstellt wurden. Ich habe nur zwei Projekte in meiner Lösung. Es ist nicht groß. Compilation mit VS2005: 30 secondes Compilation mit VS2008: 5 Minuten

Nizza Vorschläge, die bisher geholfen haben (nicht sagen, es gibt keine andere nette Vorschläge unten, wenn Sie Probleme haben, empfehle ich dann, genau das, was uns geholfen hat)

New 3GHz Laptop - die Kraft verloren Nutzung wirkt Wunder, wenn das Management whinging
Deaktivieren Anti-Virus während der Kompilierung
‚trennen‘ von VSS (eigentlich das Netz) während der Kompilierung - ich kann lernen Sie uns VS-VSS-Integration zusammen und halten Sie sich mit der VSS-Benutzeroberfläche entfernen

Noch nicht rip-schnaubend durch eine Kompilierung, aber jedes Bit hilft.

Wir testen auch die Praxis des Aufbaus neue Bereiche der Anwendung in neuen Lösungen in den neuesten dlls Import nach Bedarf, so dass sie sie in die größere Lösung zu integrieren, wenn wir mit ihnen zufrieden sind.

Wir können tun sie auch gleich vorhandenen Code durch temporäre Lösungen erstellen, die nur die Bereiche einkapseln wir arbeiten müssen, und werfen sie weg, nachdem Sie den Code zu reintegrieren. Wir müssen die Zeit abwägen es dauern wird, diesen Code gegen die Zeit uns nicht mit Rip Van Winkle wie Erfahrungen mit schnellen Neukompilierung während der Entwicklung gewinnen reintegrieren.

Orion hat in einem Kommentar erwähnen, dass Generika auch ein Spiel haben kann. Aus meinen Tests dort scheint eine minimale Leistung getroffen, aber nicht hoch genug, um sicher zu sein - kompilieren Zeiten durch Plattenaktivität inkonsequent sein können. Aus Zeitgründen, sind meine Tests nicht so viele Generika, oder so viel Code wie im Live-System erscheinen würde, reichern das kann so. Ich möchte vermeiden, nicht die Verwendung von Generika, wo sie angeblich verwendet werden, nur für Kompilierung Leistung

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow