Arm-Leistungstest

Leistungsunterschiede bei Build-Systemen machen sich auf langsameren Plattformen stärker bemerkbar. Um diesen Unterschied zu untersuchen, verglichen wir die Leistung von Meson mit GNU Autotools. Wir nahmen das GLib-Softwareprojekt und schrieben sein Build-Setup mit Meson neu. GLib wurde gewählt, da es sich um eine relativ große C-Codebasis handelt, die viele Low-Level-Konfigurationen erfordert.

Die Meson-Version des Build-Systems ist nicht vollständig äquivalent zur ursprünglichen Autotools-Version. Sie führt nicht alle gleichen Konfigurationsschritte aus und baut nicht alle gleichen Ziele. Das größte fehlende Stück ist die Internationalisierungsunterstützung mit Gettext. Sie konfiguriert das System jedoch ausreichend, um den gesamten C-Quellcode zu kompilieren und alle Unit-Tests auszuführen.

Alle Messungen wurden auf einem Nexus 4 Smartphone mit dem neuesten Ubuntu Touch-Image (aktualisiert am 9. September 2013) durchgeführt.

Messungen

Das erste, was wir gemessen haben, war die Zeit, die für den Konfigurationsschritt benötigt wurde.

Meson benötigt ungefähr 20 Sekunden, während Autotools 220 Sekunden benötigt. Das ist ein Unterschied von einer Größenordnung. Die Zeit von Autotools umfasst sowohl autogen als auch configure. Auch hier sollte man bedenken, dass Meson nicht alle Konfigurationsschritte durchführt, die Autotools durchführt. Es erledigt etwa 90% davon und benötigt dafür nur 10% der Zeit.

Dann haben wir die Build-Zeiten gemessen. Für beide Systeme wurden zwei parallele Kompilierungsprozesse verwendet.

Auf Desktop-Maschinen sind Ninja-basierte Build-Systeme 10-20% schneller als Make-basierte. Auf dieser Plattform wächst der Unterschied auf 50%. Der Unterschied ist wahrscheinlich auf die ineffizienten Festplattenzugriffsmuster von Make zurückzuführen. Ninja hält beide Kerne die ganze Zeit über besser am Laufen, was zu beeindruckenden Leistungssteigerungen führt.

Als nächstes haben wir den Fall des "leeren Builds" gemessen. Das heißt, wie lange dauert es, bis das Build-System erkennt, dass keine Änderungen vorgenommen werden müssen. Dies ist eine der wichtigsten Metriken von Build-Systemen, da sie eine harte Grenze dafür setzt, wie schnell Sie Ihren Code iterieren können. Autotools benötigt 14 Sekunden, um festzustellen, dass keine Arbeit zu erledigen ist. Meson (oder besser gesagt Ninja) benötigt nur eine Viertelsekunde.

Ein Schritt, der ziemlich viel Zeit in Anspruch nimmt, ist das Linken. Ein häufiger Fall ist, dass Sie an einer Bibliothek arbeiten und es Dutzende kleiner Test-Executables gibt, die sich mit ihr verlinken. Selbst wenn der Kompilierungsschritt schnell wäre, dauert das erneute Linken aller Test-Executables Zeit. Es ist üblich, dass Leute manuell nur eine Testanwendung mit einem Befehl wie make sometest kompilieren, anstatt alles neu zu erstellen.

Meson hat eine Optimierung für diesen Fall. Immer wenn eine Bibliothek neu kompiliert wird, prüft Meson die von ihr exportierte ABI. Wenn sich diese nicht geändert hat, überspringt Meson alle erneuten Linkschritte als unnötig. Der Unterschied, den dies macht, ist in der obigen Grafik deutlich zu sehen. In diesem Test wurde die Quelle vollständig kompiliert, dann wurde die Datei glib/gbytes.c berührt, um den erneuten Build der freigegebenen Basisbibliothek von GLib zu erzwingen. Wie zu sehen ist, linkt Autotools dann alle Test-Executables neu, die mit GLib verlinkt sind. Da Meson erkennen kann, dass die ABI gleich ist, kann es diese Schritte überspringen. Das Endergebnis ist, dass Meson in diesem sehr häufigen Anwendungsfall fast hundertmal schneller ist.

Schlussfolgerungen

Einer der Hauptnachteile von C und C++ im Vergleich zu Sprachen wie Java sind lange Kompilierungszeiten. Zumindest ein Teil der Schuld kann jedoch bei den verwendeten Build-Tools und nicht bei den Sprachen selbst oder ihren Compilern gefunden werden. Die Wahl der richtigen Werkzeuge kann die Kompilierung von C und C++ sehr nahe an sofortige Neuerstellungen bringen. Dies hat direkte Auswirkungen auf die Produktivität des Programmierers.