What the Fork - outil de visualisation de build C/C++/Rust en temps réel

• What the Fork est un outil cross-platform qui visualise en temps réel divers processus de build, notamment C/C++/Rust
• Il permet d’identifier facilement des problèmes structurels comme le manque de parallélisme ou des processus inefficaces dans les systèmes de build existants
• Il fonctionne avec tous les systèmes de build et tous les langages de programmation, avec prise en charge de make, ninja, gradle, zig, cargo et d’autres outils de build
• Grâce à la surveillance des appels système, il visualise sous forme de boîtes le temps d’exécution, les commandes et les relations de dépendance de chaque processus
• C’est un outil très utile pour l’optimisation des builds, l’analyse des goulots d’étranglement et l’amélioration des performances CI

---

Présentation et contexte

• What the Fork est un outil de visualisation de build en temps réel développé pour diagnostiquer visuellement les causes des builds lents
• Dans un projet comme LLVM, le volume de code peut à lui seul ralentir la compilation, mais la plupart des builds prennent inutilement trop de temps à cause de configurations inefficaces
• Jusqu’à présent, il était difficile d’inspecter directement les problèmes d’un build ou d’avoir une vue d’ensemble claire de ses défauts structurels, d’où le besoin d’un tel outil
• L’outil a été conçu pour être cross-platform et peut s’appliquer à tous les systèmes de build et à tous les langages

Principales fonctionnalités et utilisation

• What the Fork n’est pas un simple profileur système, mais un outil conçu pour diagnostiquer des problèmes spécifiques aux builds
• Il permet par exemple de repérer l’absence du flag -j avec make, des concentrations de temps sur un fichier ou une étape de compilation précise, ou encore des commandes exécutées séquentiellement alors qu’un traitement parallèle serait possible
• Il est particulièrement efficace pour analyser et optimiser les performances des clean builds dans les environnements CI
• L’utilisation consiste à préfixer la commande de build avec wtf (par exemple : wtf make, wtf cargo build, wtf npm run build)
• Quand le build démarre, l’interface se lance et met à jour en temps réel l’avancement de chaque processus

Interface et mode de visualisation

• Chaque processus de build est affiché sous forme de boîte sur une timeline, avec un code couleur selon le type
• Les relations parent-enfant entre les processus sont représentées par une structure imbriquée
• Le panneau inférieur affiche le temps d’exécution, le répertoire de travail et les arguments complets de la commande pour le processus sélectionné

Principe de fonctionnement

• Un build est une combinaison de plusieurs processus (par exemple bash, clang, ld)
• Les builds de grande taille utilisent divers outils comme cargo, make, bazel, gradle, xcodebuild, qui exécutent en pratique de nombreuses commandes et gèrent dépendances, cache et ordonnancement
• La seule sortie du terminal ne permet pas de comprendre les processus imbriqués (par exemple ld invoqué en interne par clang) ni la structure détaillée du timing
• Pour cela, l’outil exploite des appels système propres à chaque OS pour détecter le démarrage et la fin des processus (macOS : Endpoint Security API, Linux : ptrace(), Windows : Event Tracing for Windows, etc.)
• Cette approche permet de reconstruire l’ensemble du build et sa timeline, puis d’identifier le chemin d’exécution et la durée de chaque étape
• Il peut aussi servir au suivi de divers sous-processus au-delà des builds

Cas réels et observations

• Plusieurs ingénieurs (chez Delta, Mozilla et Apple) l’ont réellement appliqué à leurs projets et ont découvert des problèmes inattendus
• Exemple 1 : sur un projet open source utilisant Cargo, les fichiers étaient compilés séquentiellement, révélant un manque de parallélisme (avec une possibilité d’amélioration de vitesse de plus de 10x sur un CPU à 10 cœurs)
• Exemple 2 : sur un build LLVM avec Ninja, tous les cœurs CPU travaillaient efficacement en parallèle, atteignant une efficacité de build idéale
• Exemple 3 : sur un projet basé sur CMake, une structure inefficace a été mise au jour, avec des exécutions imbriquées de cmake/make/clang et 85 répétitions de vérifications de version Xcode/OS, alors que le travail réel était minime
• Exemple 4 : sur un gros projet Objective-C utilisant xcodebuild, un manque de parallélisme a été observé en fin de build, ainsi qu’une période d’inactivité de 6 secondes avant le démarrage, alors que ninja commence la compilation presque immédiatement après 0,4 seconde
• Exemple 5 : lorsque Zig compile Orca Project, l’ordre de build des dépendances est déterminé de manière aléatoire, ce qui fait varier l’efficacité du parallélisme selon la chance. Certaines dépendances s’exécutent en dernier, ce qui dégrade le parallélisme
• Exemple 6 : sur le projet GitHub CLI utilisant make/go, le téléchargement des dépendances prend beaucoup de temps. Réduire les dépendances pourrait améliorer la vitesse du build

Effets pratiques et limites

• L’analyse visuelle de la timeline permet d’identifier des goulots d’étranglement inattendus, des répétitions inutiles de dépendances et des zones où le parallélisme est insuffisant
• Elle permet de repérer rapidement des axes d’amélioration structurels — problèmes de dépendances, travail inutilement refait, inefficacité d’un outil donné — et de les exploiter directement pour optimiser les performances de build
• L’affichage de la commande complète de chaque processus permet une analyse plus fine

Programme bêta

• What the Fork fonctionne sur Windows, Linux et macOS
• Les particuliers et les équipes souhaitant faire un retour peuvent demander à rejoindre la bêta privée (lien Google Forms fourni)