Performance Engineering

Performance Engineering

0:00 Jetzt kommt das Modul zu der Zahl, die TypeScript 7 überhaupt erst in die Schlagzeilen gebracht hat. Modul 1 hat sie angerissen, Modul 5 hat sie relativiert — hier liefern wir beides nach: die vollständigen Messungen und die Werkzeuge, mit denen Sie eigene erzeugen. Denn der Leitsatz dieses Moduls lautet: Ein Faktor aus einer Ankündigung ist ein Anhaltspunkt, keine Zusage für Ihr Projekt. Am Ende dieses Moduls haben Sie eine eigene Zahl.

0:25 Und eine eigene Zahl ist im Unternehmen deutlich mehr wert als eine fremde.

Performance Engineering mit TypeScript 7

0:30 Wir gehen zunächst durch die belegten Messungen — und dabei auch durch die, die seltener zitiert werden, obwohl sie im Alltag mehr bedeuten. Dann durch die Stellschrauben: parallele Prüfung, nebenläufige Builds und den Schalter, der Messungen erst vergleichbar macht. Danach die Abwägungen zwischen Rechenkernen, Speicher und Pipeline. Und zum Schluss ein Aspekt, der neu ist: Was bedeutet Prüfzeit eigentlich für einen Coding Agent?

0:55 Die Antwort führt uns direkt ins nächste Modul.

Nativer Compiler und Language Server

0:59 Fangen wir mit einer Beobachtung an, die für Ihre Argumentation im Unternehmen wichtig ist: Die Buildzeit beeindruckt, aber der Editor entscheidet über die Akzeptanz. Wer nur Buildzahlen zeigt, verkauft am Alltag vorbei — den vollständigen Build erlebt niemand täglich, den Editor jeder. TypeScript 7 bringt zwei Neuerungen zugleich, und meist wird nur über eine gesprochen.

1:21 Die erste: ein nativ übersetzter Compiler mit paralleler Typprüfung — sie wirkt in der Pipeline. Die zweite: ein neu gebauter Sprachserver, also die Komponente, die Ihren Editor mit Wissen versorgt — sie wirkt beim Tippen. Und die zweite ist diejenige, die im Team über die Zustimmung entscheidet. Eine Pipeline, die drei Minuten schneller ist, bemerkt man beim Kaffee.

1:43 Einen Editor, der nicht mehr hängt, bemerkt man alle zwanzig Sekunden. Diese Tabelle finden Sie in keiner der üblichen Zusammenfassungen, und das ist schade — denn hier stehen die Zahlen, die den Arbeitsalltag beschreiben. Der Speicherbedarf sinkt spürbar. Fehlgeschlagene Kommandos des Sprachservers gehen um über 80 Prozent zurück, Abstürze um über 60.

2:05 Und die letzte Zeile ist die eindrucksvollste: Eine Datei mit einem Fehler zu öffnen dauerte 17,5 Sekunden und dauert jetzt unter 1,3. Denken Sie kurz darüber nach, was 17 Sekunden Wartezeit mit der Aufmerksamkeit machen — in dieser Zeit ist der Gedanke weg. Vier Gründe, und der letzte ist mein praktischer Rat für Ihre interne Kommunikation. Der vollständige Build läuft selten, der Sprachserver dauernd.

2:30 Abstürze und hängende Kommandos kosten Vertrauen, nicht nur Zeit — und verlorenes Vertrauen in Werkzeuge holt man schwer zurück. Kurze Antwortzeiten ändern das Arbeitsverhalten, lange übrigens auch, nur in die andere Richtung. Und deshalb: Die Buildzahlen überzeugen die Leitung, die Editor-Zahlen das Team. Sie brauchen beide, und Sie brauchen sie für verschiedene Gespräche.

Parallele Typprüfung mit checkers

2:53 Jetzt zur ersten Stellschraube: der parallelen Typprüfung. Vier Arbeiter sind voreingestellt. Und die wichtigste Botschaft gleich vorweg, weil der Reflex ein anderer ist: mehr ist nicht automatisch besser. Die Einstellung bestimmt, wie viele unabhängige Prüf-Arbeiter laufen — jeder mit einer eigenen Sicht auf die Typinformation.

3:13 Und genau in diesem Nebensatz steckt der Preis: eine eigene Sicht heißt eigener Speicher. Voreingestellt sind vier, getestet wurde bis acht, das Minimum ist einer. Die Ankündigung sagt es ausdrücklich: Mehr Arbeiter heißt mehr Speicher. Das Bild dazu: Mehr Köche in der Küche kochen schneller — aber jeder braucht seine eigene Arbeitsfläche, und irgendwann ist die Küche voll.

3:36 Drei Aufrufe, drei Situationen. Der Standard ohne Angabe für den Alltag. Die erhöhte Zahl für eine große Maschine, auf der Speicher kein Thema ist. Und der einzelne Arbeiter — der ist nicht etwa der Sparmodus, sondern das Werkzeug für Diagnose und Vergleich; dazu kommen wir gleich ausführlich. Die Fußzeile zitiert die Ankündigung wörtlich, und ich mag die Formulierung: mehr Arbeiter beschleunigen den Build weiter, üblicherweise zu Lasten des Speichers.

4:04 „Zu Lasten" — das ist eine Abwägung, keine Verbesserung. Der erste Punkt ist der teuerste in der Pipeline: die Zahl hochdrehen, ohne den Speicher des Ausführungsknotens zu kennen. Das Ergebnis ist oft langsamer, nicht schneller — warum, sehen wir in Kapitel 5. Der zweite ist eine Maßfrage: auf einem kleinen Projekt parallelisieren, wo allein die Verwaltung der Arbeiter mehr kostet als sie einspart.

4:28 Und der dritte ist ein Methodenfehler, der jede Messung entwertet: verschiedene Werte vergleichen, ohne sonst etwas konstant zu halten. Dazu gleich mehr — das ist der Kern dieses Moduls.

Nebenläufige Builds mit builders

4:40 Die zweite Stellschraube betrifft Monorepos mit vielen Teilprojekten. Sie wirkt auf einer anderen Ebene als die erste — und sie wirkt mit ihr zusammen, und zwar multiplikativ. Das ist der Punkt, den man kennen muss, bevor man an beiden dreht. Diese Einstellung bestimmt, wie viele Teilprojekte gleichzeitig gebaut werden. Und jetzt die Rechnung, die man im Kopf haben muss: Sie wirkt multiplikativ mit der ersten.

5:05 Vier Builder mit je zwei Prüf-Arbeitern sind acht Prozesse — nicht sechs. Wer beide Zahlen unabhängig voneinander hochsetzt, bekommt schnell eine Prozesszahl, die er nicht beabsichtigt hat. Wichtig ist noch der letzte Satz: Eine andere Zahl soll keine anderen Ergebnisse liefern, nur andere Laufzeiten. Merken Sie sich das als Prüfkriterium.

5:26 Oben nur die Teilprojekte nebenläufig, unten beide Schrauben zusammen — und damit acht gleichzeitige Prozesse. Die Fußzeile enthält eine Aussage, die Sie als Prüfstein mitnehmen sollten: Ein anderer Wert darf das Ergebnis nicht verändern. Tut er es doch — bekommen Sie also mit vier Buildern andere Fehler als mit einem —, dann ist das ein Befund und keine Einstellungsfrage.

5:47 Dann stimmt etwas mit Ihren Abhängigkeiten nicht, und Sie haben ein echtes Problem gefunden, das vorher nur nicht sichtbar war. Vier Punkte, und der erste korrigiert eine naheliegende Annahme: Der Gewinn hängt an der Form des Abhängigkeitsgraphen, nicht an der Zahl der Pakete. Eine flache, breite Struktur profitiert stark, weil vieles gleichzeitig gehen kann.

6:08 Eine lange Kette kaum — dort wartet jedes Glied auf das vorige, egal wie viele Arbeiter Sie haben. Und ein Teilprojekt, von dem alle abhängen, ist der Flaschenhals, an dem sich alles staut. Deshalb der Rat: Wer hier gewinnen will, schneidet zuerst die Referenzen und dann die Schalter.

singleThreaded

6:26 Jetzt zu einem Schalter, der auf den ersten Blick nach Rückschritt aussieht und in Wahrheit das wichtigste Werkzeug dieses Moduls ist. Er begrenzt die Prüfung auf einen einzigen Faden — und macht damit Messungen überhaupt erst vergleichbar. Der Schalter begrenzt die Prüfung auf einen Arbeiter und sorgt zusätzlich dafür, dass auch Einlesen und Ausgeben einfädig laufen.

6:46 Die Ankündigung empfiehlt ihn für vier Situationen: für die Fehlersuche, für den Vergleich von Laufzeiten, für extern orchestrierte Builds und für Umgebungen mit sehr knappen Ressourcen. Die zweite ist die für uns entscheidende, und sie steht dort ausdrücklich. Genau darauf baut das Messprotokoll auf, das wir gleich durchgehen.

7:05 Ohne diesen Schalter messen Sie nicht den Compiler, sondern die Tagesform Ihrer Maschine. Vier Einsatzzwecke, und der erste ist der, um den es hier geht: reproduzierbare Zeiten — die Voraussetzung für jeden Vergleich. Solange mehrere Arbeiter um Rechenkerne konkurrieren, schwankt jeder Lauf, und Sie messen Rauschen. Dazu kommt die Fehlersuche, wenn sich ein Lauf nicht deterministisch verhält.

7:28 Dann Container mit wenigen Kernen, wo Parallelität nur noch verwaltet statt gearbeitet wird. Und schließlich der Fall, dass eine äußere Orchestrierung die Parallelität ohnehin schon steuert — dann sollten Sie es nicht doppelt tun. Der zweite Punkt ist der Methodenfehler, den ich am häufigsten sehe: ohne diesen Schalter messen und die Schwankung für einen Effekt halten.

7:49 Sie messen dreimal, bekommen drei verschiedene Zahlen und lesen einen Trend hinein, der keiner ist. Der erste Punkt ist der umgekehrte Fehler: den Schalter im Alltag gesetzt lassen und sich dann über die Laufzeit wundern — er ist ein Messwerkzeug, kein Betriebsmodus. Und der dritte klärt ein Missverständnis: Er ist kein Kompatibilitätsschalter. Am Ergebnis ändert er nichts, nur an der Zeit.

Trade-offs zwischen CPU, Speicher und CI

8:12 Jetzt zur Abwägung, die in der Pipeline am häufigsten schiefgeht. Der Satz dazu ist kurz und folgenreich: Parallelität kostet Arbeitsspeicher, und zwar zuerst. Nicht Rechenzeit, nicht Bandbreite — Speicher. Vier Umgebungen, vier Empfehlungen. Auf dem Entwicklerrechner ist selten etwas knapp — lassen Sie den Standard. Auf einem großen Ausführungsknoten können Sie erhöhen, aber messen Sie dabei.

8:37 Im kleinen Container ist der Speicher knapp; dort senken Sie die Zahl und gehen im Zweifel auf einen Faden zurück. Und beim Monorepo-Build müssen Sie beide Schalter zusammen denken, wegen der multiplikativen Wirkung. Die interessanteste Zeile ist die dritte — dort ist weniger tatsächlich schneller, und das erklärt die nächste Folie.

8:58 Die Mechanik dahinter ist einfach und lohnt sich zu kennen. Jeder Arbeiter hält eine eigene Sicht auf die Typinformation im Speicher. Reicht der Speicher nicht mehr, beginnt das Betriebssystem auszulagern — es schiebt Daten auf die Festplatte. Und ein ausgelagerter Prozess ist um Größenordnungen langsamer als gar keine Parallelität.

9:17 Sie haben also einen Punkt, ab dem jede weitere Erhöhung nicht nur nichts bringt, sondern schadet — und zwar plötzlich, nicht allmählich. Deshalb gehört die Ausstattung Ihrer Pipeline zur Performance-Entscheidung dazu.

Messen statt annehmen

9:30 Und jetzt zur Position dieses Seminars, und ich sage ausdrücklich dazu: Das ist unsere Haltung, nicht die des Herstellers. Die Ankündigung gibt keine Messanleitung. Der Grundsatz und das Protokoll sind unsere — gestützt auf die beträchtliche Spannweite der belegten Zahlen. Sehen Sie sich die Spannweite an: Faktor 11,9 beim Hersteller an einer sehr großen Codebasis, rund Faktor 3 bei einem realen Monorepo.

9:55 Und das Projekt nennt den Grund selbst — nur ein Teil der Pipeline-Zeit steckte je in der Typprüfung. Beide Zahlen sind richtig, keine ist geschönt, und sie unterscheiden sich um das Vierfache. Der Schluss daraus ist unausweichlich: Keine sagt etwas über Ihr Projekt. Wer eine Zahl braucht, muss sie erheben. Und das ist erfreulicherweise in einer Stunde zu schaffen.

10:17 Fünf Schritte, und Schritt drei ist der meistübersehene, wie die Fußzeile sagt: vollständigen Build und inkrementellen Lauf getrennt erfassen. Der Alltag trifft deutlich häufiger auf inkrementelle Läufe — und ausgerechnet über die sagen die veröffentlichten Zahlen nichts. Davor: dieselbe Maschine, dieselbe Codebasis, derselbe Stand. Einfädig messen, damit die Läufe reproduzierbar sind.

10:40 Danach die Parallelität stufenweise erhöhen und jeden Lauf mitschreiben. Und zum Schluss den Punkt notieren, ab dem nichts mehr dazukommt — das ist Ihre eigentliche Erkenntnis. Der erste Punkt ist der Karrierefehler dieses Moduls: fremde Faktoren im Unternehmen zusagen und die eigene Messung nachreichen. Messen Sie zuerst, sagen Sie danach zu.

11:01 Der zweite ist der Messfehler von eben: nur den vollständigen Build messen, den fast niemand täglich ausführt. Und der dritte ist ein handwerklicher: die erste Messung nach dem Wechsel nehmen, wenn die Zwischenspeicher noch kalt sind. Der erste Lauf misst fast immer etwas anderes als den Compiler. Deshalb messen wir dreimal.

Große Projekte und Monorepos

11:21 Jetzt eine Einsicht, die manchen enttäuscht und viel Zeit spart: In großen Codebasen sind die üblichen Bremsen selten der Compiler. Sie sind die Struktur. Und die holt keine Compileroption zurück. In großen Codebasen kostet selten die Compilergeschwindigkeit die meiste Zeit, sondern die Struktur — und zwar drei Dinge im Besonderen: übermäßig komplexe Typkonstruktionen, zirkuläre Abhängigkeiten und ein Projektumfang, der mehr Dateien einschließt als nötig.

11:49 Der letzte Punkt ist der am häufigsten unterschätzte: Viele Projekte prüfen mehr, als sie ausliefern, ohne dass es jemandem aufgefallen wäre. Und der Kernsatz: Diese Kosten holt keine Compileroption zurück. Ein schnellerer Motor fährt die Umleitung nicht kürzer — denselben Satz hatten wir in Modul 5. Eine Reihenfolge zum Mitnehmen, und sie endet bewusst mit den Schaltern. Zuerst der Projektumfang: Wie viele Dateien werden überhaupt geprüft?

12:15 Diese Zahl überrascht in fast jedem gewachsenen Projekt. Dann die Typkonstruktionen aus Modul 5 — pathologisch bleibt pathologisch, auch mit schnellerem Compiler. Dann zirkuläre Abhängigkeiten zwischen Teilprojekten. Und erst danach die Schalter. Sie sind die letzte Stellschraube, nicht die erste — auch wenn sie die verlockendste ist, weil man an ihnen ohne Umbau drehen kann.

12:38 Der erste Punkt fasst die vorige Folie zusammen: an den Schaltern drehen, bevor der Projektumfang geprüft ist. Der zweite ist ein konkreter Fall davon und knüpft an Modul 9 an: die Typpakete weit fassen und damit fremde Typen mitprüfen. Seit Version 6.0 müssen Sie sie ohnehin ausdrücklich nennen — nutzen Sie die Gelegenheit, sparsam zu sein.

12:59 Und der dritte kennen wir aus Modul 7: Projektreferenzen so schneiden, dass fast jede Änderung fast alles neu baut. Dann ist die Inkrementalität nur auf dem Papier vorhanden.

Feedbackschleifen für Menschen und Agenten

13:10 Zum Abschluss ein Blickwinkel, der vor zwei Jahren noch nicht existierte. Die Tagline bringt ihn auf den Punkt: Was für einen Menschen eine Pause ist, ist für einen Agenten der Takt. Und damit sind wir an der Brücke zum nächsten Modul. Ein Mensch führt die Typprüfung einige Male am Tag aus und überbrückt die Wartezeit — mit Kaffee, mit einer anderen Datei, mit einem Gedanken.

13:32 Ein Coding Agent führt sie innerhalb einer einzigen Aufgabe vielfach aus, weil jede Änderung eine Prüfung nach sich zieht. Und er kann nichts überbrücken; er wartet. Damit ist Prüfzeit dort kein Komfortthema mehr, sondern sie bestimmt, wie viele Schritte in einer Sitzung überhaupt möglich sind. Aus einer Bequemlichkeitsfrage wird eine Frage der Arbeitsfähigkeit.

13:54 Vier Wirkungen, und sie gelten für Menschen wie für Maschinen. Kleinere Änderungsschritte, weil jeder Schritt sofort geprüft wird — und kleine Schritte sind besser überprüfbar. Prüfung nach jedem Schritt statt am Ende einer langen Kette, wo man dann fünf verschränkte Fehler gleichzeitig hat. Ein Agent kann Fehler selbst beheben, bevor sie überhaupt jemanden erreichen. Und der vierte fasst es zusammen: Die Prüfung wird zum Werkzeug statt zur Hürde.

14:19 Genau darum ging es in Modul 8 bei den Toren — nur dass es hier die Geschwindigkeit ist, die den Unterschied macht.

Übung — selbst messen

14:26 Jetzt messen Sie selbst. Und am Ende steht eine eigene Zahl, keine fremde — das ist das Ziel der Übung und zugleich ihr Wert für Ihre Arbeit. Die Voraussetzung haben wir in Modul 9 geschaffen: den Parallelbetrieb beider Compilerfassungen. Das Lernziel: die Wirkung des Compilerwechsels und der Parallelität im eigenen Projekt belastbar messen, statt sie zu schätzen.

14:49 Erfolgreich sind Sie, wenn eine Messreihe vorliegt, aus der hervorgeht, ab welchem Wert zusätzliche Parallelität nichts mehr bringt — und zwar mit genannten Randbedingungen. Diese Randbedingungen sind kein Beiwerk: Eine Zahl ohne Maschine, Kerne und Speicher ist nicht überprüfbar und damit wertlos. Wer früh fertig ist, misst zusätzlich den inkrementellen Lauf und vergleicht das Verhältnis mit dem vollständigen Build.

15:13 Fünf Schritte, und die Fußzeile begründet den zweiten: Dreimal messen ist kein Übermaß, denn der erste Lauf misst fast immer die Zwischenspeicher mit statt den Compiler. Zuerst halten Sie die Randbedingungen fest — Maschine, Kerne, Speicher, Stand. Dann messen Sie beide Fassungen einfädig, je dreimal. Danach erhöhen Sie die Parallelität stufenweise und schreiben jeden Lauf mit. Sie bestimmen den Punkt, ab dem nichts mehr dazukommt.

15:38 Und im letzten Schritt vergleichen Sie mit den Zahlen aus Modul 1 und 5. Dieser Vergleich ist meistens die interessanteste Minute des Moduls. Vier Sätze zum Mitnehmen. Vier Prüf-Arbeiter sind Standard, mehr kostet Speicher und hilft nicht überall. Die beiden Schalter wirken multiplikativ und ändern nie das Ergebnis — tun sie es doch, haben Sie einen Befund.

16:01 Einfädig messen ist die Voraussetzung dafür, dass ein Vergleich überhaupt etwas aussagt. Und die Struktur bremst häufiger als der Compiler; Schalter sind die letzte Schraube, nicht die erste. Damit endet der technische Teil. Ab dem nächsten Modul geht es um die Zusammenarbeit mit Coding Agents.