Ein einfacher Vergleich
In diesem Experiment haben wir eintausend C-Dateien mit folgendem Inhalt generiert.
#include<stdio.h>
#include"header.h"
int func23() { return 0; }
Die Funktionsnummer war in jeder Datei unterschiedlich. Zusätzlich gab es eine Haupt-C-Datei, die jede Funktion der Reihe nach aufrief. Wir haben dann Build-System-Dateien für Meson, CMake, SCons, Premake und Autotools generiert, die diese Dateien zu einer einzigen ausführbaren Datei kompilierten.
Damit haben wir drei verschiedene Dinge gemessen. Das erste ist die Konfigurationszeit, d. h. die Zeit, die das Build-System benötigt, um die notwendigen Build-Dateien zu generieren. Dies wird normalerweise als Configure-Schritt bezeichnet. Die Zeit wurde in Sekunden gemessen.
Das zweite zu messende war die Build-Zeit. Diese sollte durch den Compiler begrenzt sein und im optimalen Fall für jedes Build-System gleich sein. Bei diesem Test wurden vier parallele Prozesse verwendet.
Das dritte, was wir gemessen haben, war die leere Build-Zeit. Dies misst, wie viel Zeit das Build-System benötigt, um die Zustände aller Quelldateien zu überprüfen, da jede einzelne potenziell einen Neubau verursachen könnte.
Da CMake zwei verschiedene Backends hat, Make und Ninja, haben wir die Tests auf beiden ausgeführt. Alle Tests wurden auf einem MacBook Pro aus dem Jahr 2011 mit Ubuntu 13/04 durchgeführt. Die Tests wurden mehrmals durchgeführt und wir haben immer die schnellste Zeit genommen.
Hier sind die Ergebnisse für die Konfigurationszeit.
Der Grund, warum SCons bei diesem Test null Sekunden benötigte, liegt darin, dass Konfigurations- und Build-Schritte nicht getrennt werden können. Sie laufen als eine Einheit. Autotools ist der klare Verlierer dieses Tests, da es mehr als eine Größenordnung langsamer ist als das zweitschnellste. Diese Konfigurationszeit beinhaltet sowohl autogen als auch configure. Alle anderen Systeme benötigen weniger als eine Sekunde für diese Einrichtung, was schnell genug ist, damit ein Mensch es als augenblicklich empfindet.
Build-Zeiten sind etwas gleichmäßiger. SCons ist das langsamste und benötigt fast zehn Sekunden länger als das zweitschnellste. Ein Teil davon ist Arbeit aus dem Konfigurationsschritt, aber es hat immer noch die schlechteste Leistung. Premake ist das schnellste Make-basierte Build-System und schlägt Autotools knapp. Beide Ninja-basierten Build-Systeme sind schneller als alle Nicht-Ninja-Systeme, wobei Meson geringfügig schneller ist. In der Praxis ist der Unterschied minimal. Die Vorteile von Ninja zeigen sich, wenn man die Zeiten von CMake beim Verwenden von Make oder Ninja vergleicht. Es ist möglich, 3,5 Sekunden (über 20%) der gesamten Build-Zeit einzusparen, nur durch die Änderung des Backends. Die CMake-Konfigurationsdateien des Projekts müssen nicht geändert werden.
Leere Build-Zeiten spiegeln die Leistung der regulären Build-Zeiten wider. SCons ist wieder das langsamste und benötigt über drei Sekunden im Vergleich zu Meson, das nur 0,03 Sekunden benötigt, ein Unterschied von zwei Größenordnungen. Selbst Autotools, das schnellste Make-basierte System, ist fast eine Größenordnung langsamer. Ninja hält die Spitzenpositionen wie im vorherigen Test.
Schlussfolgerungen
Die Leistung des Build-Systems spielt eine Rolle. Selbst bei diesem extrem einfachen Beispiel können wir Unterschiede zwischen verschiedenen beliebten Build-Systemen feststellen. Mit zunehmender Projektgröße wachsen diese Unterschiede noch weiter an. (Der Autor hat No-Op-Build-Zeiten von 30 Sekunden für Make im Vergleich zu weniger als einer Sekunde für Ninja beim Kompilieren des Clang-Compilers beobachtet.) Niedrige inkrementelle Build-Zeiten sind einer der Hauptschlüssel für die Produktivität von Entwicklern, da sie es den Entwicklern ermöglichen, schneller zu iterieren und in der kreativen Zone zu bleiben.
Original-Skripte
Wer diese Experimente selbst durchführen möchte, kann die Skripte hier herunterladen
Die Ergebnisse der Suche sind