Sind wir schon Turbo?

Luke Sandberg, Software-Ingenieur bei Vercel, stellt sich und seine Arbeit an Turbo Pack vor. Er kam von Google und war überrascht von den Zielen des Vercel-Teams. Der Vortrag wird die Designentscheidungen von Turbo Pack beleuchten, die auf der bereits bestehenden Leistung aufbauen sollen. Das übergeordnete Designziel deutet auf die Notwendigkeit schwieriger Entscheidungen hin, um die angestrebte Performance zu erreichen.

Der Sprecher betont, dass Kalt-Builds zwar wichtig sind, aber idealerweise gar nicht erst erlebt werden sollten. Die zentrale Idee zur Verbesserung der Bundling-Leistung ist die Inkrementalität, die durch umfassendes Caching erreicht wird. Ziel ist es, jede Operation im Bundler cachebar zu machen, sodass bei Änderungen nur die direkt betroffene Arbeit wiederholt werden muss. Die Kosten eines Builds sollen mit der Größe der Änderung skalieren, nicht mit der Komplexität der gesamten Anwendung, um konstante Leistung zu gewährleisten. Ein naives "Baby-Bundler"-Beispiel zeigt die Probleme redundanter Arbeit ohne Inkrementalität, wie mehrfaches Parsen und Auflösen von Imports.

Zunächst wird ein einfacher Cache für die Parse-Funktion vorgestellt, der jedoch schnell an seine Grenzen stößt. Probleme wie Dateiänderungen, Symlinks, unterschiedliche Build-Ziele (Client/Server) und die Mutation von ASTs machen einen einfachen Cache unzureichend. Eine erweiterte Version, die Transforms und Konfiguration in den Cache-Schlüssel einbezieht, wird als zu komplex und fehleranfällig für Entwickler kritisiert. Die manuelle Invalidierungslogik über Callbacks führt zu einem "reaktiven Bundler", der aber immer noch das gesamte Bundle neu ausführt, anstatt nur inkrementelle Änderungen zu verarbeiten. Das manuelle Verwalten von Caches für Imports, Resolve-Ergebnisse und Output-Generierung mit Callbacks wird als unübersichtlich und unpflegbar dargestellt.

Der Sprecher leitet aus den Problemen des naiven Ansatzes konkrete Anforderungen an ein robustes Bundler-System ab. Es soll jede teure Operation einfach cachebar machen und die manuelle Verfolgung von Inputs oder Abhängigkeiten durch Entwickler überflüssig machen. Das System muss automatisch korrekte Cache-Schlüssel generieren und narrensicher sein. Weiterhin muss es reaktiv auf sich ändernde Inputs wie Dateien, Konfigurationen oder Umgebungsvariablen reagieren können, ohne dass Callbacks manuell durchgereicht werden müssen. Schließlich soll das System moderne Architekturen nutzen, um Multi-Threading und hohe Geschwindigkeit zu gewährleisten.

Die vorgestellten Anforderungen führen zu einem System, das dem Konzept von "Signals" ähnelt, inspiriert vom Rust-Compiler und Systemen wie Salsa (Adaptons). Turbo Pack implementiert dies mit "TurboTask"-Funktionen, die als gecachte Arbeitseinheiten dienen und automatisch Abhängigkeiten verfolgen. "VC" (Value Cell)-Typen repräsentieren reaktive Werte; wenn sie gelesen werden, wird eine Abhängigkeit registriert. Bei einer Änderung wird das Ergebnis der "TurboTask"-Funktion mit dem vorherigen verglichen, und nur bei einer tatsächlichen Wertänderung werden nachfolgende Abhängigkeiten invalidiert und neu berechnet. Dies ermöglicht beispielsweise, dass bei einer Moduländerung, die die Imports nicht beeinflusst, nachfolgende Schritte wie Chunking oder Tree Shaking nicht erneut ausgeführt werden müssen, was zu sehr schnellen Refresh-Zeiten führt.

Das System wird als ein Graph von Knoten beschrieben, bei dem ein Kalt-Build den vollständigen Abhängigkeitsgraphen erstellt und ein Warm-Build diesen nutzt, um Invalidierungen effizient zu propagieren. In der Praxis umfasst Turbo Pack heute etwa 2.500 "TurboTask"-Funktionen und Millionen von Aufgaben in einem typischen Build. Der Sprecher geht auf die Kompromisse dieses Ansatzes ein, darunter der Overhead des Systems durch die Verfolgung vieler ungenutzter Abhängigkeiten und der erhöhte Speicherverbrauch. Algorithmen, die globale Informationen benötigen, müssen sorgfältig entworfen werden, um die Inkrementalität zu bewahren. Zudem erschwert die Asynchronität des Rust-Codes das Debugging, was Investitionen in benutzerdefinierte Visualisierungs- und Tracing-Tools erforderlich macht.

Die Leistungsfähigkeit von Turbo Pack wird anhand von Vercels großer Produktionsanwendung (ca. 80.000 Module) demonstriert. Turbo Pack übertrifft Web Pack deutlich bei Fast Refresh-Zeiten und zeigt einen dreifachen Gewinn bei Kalt-Builds (94s vs. 290s), wobei das experimentelle Dateisystem-Caching noch optimiert wird. Besonders beeindruckend sind die Warm-Build-Zeiten von nur 2 Sekunden, da der Cache von der Festplatte wiederverwendet wird. Auch bei kleineren Anwendungen wie der react.dev-Website, die den React-Compiler nutzt, zeigt Turbo Pack Vorteile, indem es nach der Compiler-Verarbeitung schnell zum Output springt, wenn sich Imports nicht geändert haben. Der Sprecher bestätigt, dass Turbo Pack ab Next 16 stabil und der Standard-Bundler ist, betont aber, dass die Entwicklung noch nicht abgeschlossen ist und weitere Leistungsverbesserungen sowie die Finalisierung des Dateisystem-Cachings anstehen.