- What the Fork ist ein plattformübergreifendes Tool, das verschiedene Build-Prozesse wie C/C++/Rust in Echtzeit visualisiert
- Strukturelle Probleme bestehender Build-Systeme wie mangelnde Parallelisierung und ineffiziente Prozesse lassen sich damit leicht erkennen
- Funktioniert mit allen Build-Systemen und Programmiersprachen und unterstützt verschiedene Build-Tools wie make, ninja, gradle, zig und cargo
- Über Systemaufruf-Monitoring werden Laufzeit, Befehle und Abhängigkeiten jedes Prozesses in Form von Boxen visualisiert
- Ein sehr nützliches Tool für Build-Optimierung, Engpassanalyse und die Verbesserung der CI-Performance
Einführung und Hintergrund
- What the Fork ist ein Echtzeit-Tool zur Build-Visualisierung, das entwickelt wurde, um die Ursachen langsamer Builds visuell zu diagnostizieren
- Bei Projekten wie LLVM kann die Kompilierung wegen der schieren Code-Menge langsam sein, aber die meisten Builds dauern vor allem wegen ineffizienter Konfigurationen unnötig lange
- Bisher war es schwierig, Probleme im Build direkt zu erkennen oder strukturelle Schwächen auf einen Blick zu erfassen, weshalb ein solches Tool nötig war
- Das Tool wurde plattformübergreifend konzipiert und ist auf alle Build-Systeme und Sprachen anwendbar
Hauptfunktionen und Verwendung
- What the Fork ist kein einfacher System-Profiler, sondern ein Tool zur Diagnose build-spezifischer Probleme
- Beispiele sind das Fehlen des
-j-Flags bei make, Zeitballungen bei bestimmten Dateien oder Kompilierungsschritten sowie das Erkennen von Befehlen, die trotz möglicher Parallelisierung sequentiell ausgeführt werden
- Besonders wirksam ist es bei der Analyse und Optimierung der Clean-Build-Performance in CI-Umgebungen
- Verwendet wird es, indem der Befehl
wtf vor den eigentlichen Build-Befehl gesetzt wird (z. B. wtf make, wtf cargo build, wtf npm run build)
- Sobald der Build startet, wird die UI geöffnet und aktualisiert den Fortschritt jedes Prozesses in Echtzeit
UI und Visualisierung
- Jeder Build-Prozess wird als Box auf einer Zeitleiste dargestellt und per Farbe typisiert
- Die Eltern-Kind-Beziehungen der Prozesse werden als verschachtelte Struktur angezeigt
- Im unteren Panel werden Laufzeit, Arbeitsverzeichnis und vollständige Befehlsargumente des ausgewählten Prozesses angezeigt
Funktionsweise
- Ein Build ist eine Kombination aus mehreren Prozessen (z. B.
bash, clang, ld)
- Große Builds verwenden verschiedene Build-Tools wie
cargo, make, bazel, gradle und xcodebuild, die tatsächlich viele Befehle, Abhängigkeiten, Caches und Scheduling-Aufgaben ausführen
- Allein anhand der Terminalausgabe lassen sich verschachtelte Prozesse (z. B.
ld, das intern von clang aufgerufen wird) und die detaillierte Timing-Struktur nicht erfassen
- Deshalb nutzt das Tool je nach Betriebssystem Systemaufrufe zur Erkennung von Prozessstart und -ende (macOS: Endpoint Security API, Linux: ptrace(), Windows: Event Tracing for Windows)
- Auf diese Weise lassen sich der gesamte Build-Ablauf und die Zeitleiste rekonstruieren sowie Ausführungspfade und Laufzeiten der einzelnen Schritte identifizieren
- Es kann nicht nur für Builds, sondern auch zur Verfolgung verschiedener anderer Subprozesse eingesetzt werden
Praxisbeispiele und Beobachtungen
- Mehrere Ingenieure (von Delta, Mozilla und Apple) haben das Tool tatsächlich in Projekten eingesetzt und dabei unerwartete Probleme entdeckt
- Beispiel 1: In einem Open-Source-Projekt mit Cargo wurde festgestellt, dass Dateien sequentiell kompiliert wurden, also zu wenig Parallelität vorhanden war (bei einer 10-Kern-CPU wurde ein Beschleunigungspotenzial von mehr als dem 10-Fachen festgestellt)
- Beispiel 2: Bei einem LLVM-Build mit Ninja arbeiteten alle CPU-Kerne effizient parallel und erreichten eine ideale Build-Effizienz
- Beispiel 3: In einem CMake-basierten Projekt wurde eine ineffiziente Struktur entdeckt, bei der verschachtelte Aufrufe von cmake/make/clang sowie erneute Prüfungen von Xcode-/OS-Versionen 85-mal wiederholt wurden (die eigentliche Arbeit machte nur einen sehr kleinen Teil aus)
- Beispiel 4: In einem großen Objective-C-Projekt mit xcodebuild wurde gegen Ende des Builds zu wenig Parallelisierung beobachtet, außerdem gab es vor dem Build-Start eine sechssekündige Inaktivitätsphase (im Vergleich dazu begann ninja schon nach 0,4 Sekunden direkt mit der Kompilierung)
- Beispiel 5: Wenn Zig das Orca Project kompiliert, wird die Reihenfolge der Abhängigkeits-Builds zufällig festgelegt, wodurch die Effizienz der Parallelisierung vom Glück abhängt. Es wurde beobachtet, dass manche Abhängigkeiten erst ganz am Ende ausgeführt werden und dadurch die Parallelität sinkt
- Beispiel 6: Im GitHub-CLI-Projekt mit make/go ist die Zeit für das Herunterladen von Abhängigkeiten hoch. Durch eine Reduzierung der Abhängigkeiten ist eine schnellere Build-Zeit zu erwarten
Nutzen und Grenzen
- Durch die Analyse der visuellen Zeitleiste lassen sich unerwartete Engpässe, unnötige Wiederholungen von Abhängigkeiten und Bereiche mit zu wenig Parallelität erkennen
- Probleme bei Abhängigkeiten, unnötige Nacharbeit oder Ineffizienzen bestimmter Tools lassen sich schnell als strukturelle Verbesserungsmöglichkeiten identifizieren und direkt zur Optimierung der Build-Performance nutzen
- Durch die Einsicht in den vollständigen Befehl jedes Prozesses ist eine noch detailliertere Analyse möglich
Beta-Programm
- What the Fork läuft unter Windows, Linux und macOS
- Einzelpersonen und Teams, die Feedback geben möchten, können sich für die private Beta anmelden (Google-Formular-Link vorhanden)
Noch keine Kommentare.