.NET Build Performance optimieren!

In den letzten Wochen hatte ich die die Möglichkeit Strategien für Beschleunigung von Builds mit Visual-Studio 2008 und MsBuild zu untersuchen. Hier meine Ergebnisse.

1:) Multiprozessor Build

MSBuild-Multithreaded

Visual Studio unterstützt beim Build per Default nur eine Thread. Doch es geht mehr! Das Zauberwort heißt: "msbuild /m".

Detailiert wird das Problem und die Lösung von Scott Hanselman beschrieben:

2:) Einzelnes Output Directory und keine "lokalen Kopien".

Per Default werden Build Ergebnisse in /projekt/bin/<Target>/ kopiert. Alle abhängigen Assemblies werden per Default ebenso kopiert, also auch Build-Ergebnisse anderer Projekte.

Nehmen wir eine Beispiel-Solution mit 50 Projekten. Jedes Projekt hat ungefähr 10.000 Zeilen Code und nehmen wir an die 50 Projekte sind gerechtfertigt. Wenn jedes Projekt mehrfach von anderen Projekten referenziert wird und 10.000 Zeilen ohne .resx Dateien eine DLL Größe von ca.: 250kb ergeben und eine PDB Größe von ca.:500kb, dann ergeben sich, wenn jedes Projekt ungefähr 10x referenziert wird , 10x750kb*50 - also 375 MB zu kopierende Daten. Obwohl eigentlich nur 37MB kopiert werden müssten. Die Lösung für das Problem? Das Build in ein einzelnes Verzeichnis durchführen, ohne die Abhängigen immer wieder zu kopieren. Hierfür muss neben der Pfadangabe für das OutputDirectory folgende Einstellung vorgenommen werden:

Copy-Local

3:) Abhängigkeiten minimieren

Wenn I/O Zeiten (siehe 2) kein Problem sind und alle verfügbaren Kerne ausgelastet sind (siehe 1), dann ist der größte verbleibende Zeitfaktor das Auflösen von Abhängigkeiten.

Eine Analyse lässt sich mit dem MSBUILD-Profiler durchführen. 

MSBuild-Profiler

Lösung des Problems? Weniger Abhängigkeiten und Projekte zusammenfassen :-)

4:) .licx Dateien nicht Teil des Projekts

LC.exe ist langsam. Es lässt sich Build Zeit sparen, wenn Lizenz-Informationen nur bei Bedarf in die Assembly "gebaut" werden. .licxs Dateien sollten nicht eingecheckt werden und nicht Teil des Dev-Builds sein.

Was noch?

Solutions entkoppeln und Modular arbeiten? Klar :-) Ein schnelle Entwicklungsmaschine hilft, eine gute SSD Platte und ein schneller Prozessor helfen. Wenn man damit nicht mehr weiterkommt, dann gilt es die Solution zu zerlegen. Als Richtwert sollte ein Clean-Build von 500.000 Zeilen Code (Nettozeilen ohne Kommentare) unter einer Minute liegen.

Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Dezember 11. 2009 06:47

trackback

.NET Build Performance optimieren!

Sie wurden gekickt (eine gute Sache) - Trackback von  dotnet-kicks.de

dotnet-kicks.de

Kommentar schreiben


(Zeigt dein Gravatar icon)

  Country flag

biuquote
  • Kommentar
  • Live Vorschau
Loading