John Carmacks Performance-Denkweise für Echtzeitgrafik

Warum Carmacks Ansatz weiterhin wichtig ist

John Carmack wird oft wie eine Legende der Spiele‑Engines behandelt, aber das Nützliche ist nicht die Mythologie – es sind die wiederholbaren Gewohnheiten. Es geht nicht darum, den Stil einer Person zu kopieren oder „geniale Züge“ anzunehmen. Es geht um praktische Prinzipien, die zuverlässig zu schnellerer, flüssigerer Software führen, besonders wenn Deadlines und Komplexität wachsen.

Performance‑Engineering, in einfachen Worten

Performance‑Engineering bedeutet, Software so zu gestalten, dass sie ein Geschwindigkeitsziel auf realer Hardware unter realen Bedingungen erreicht – ohne die Korrektheit zu brechen. Es ist nicht „mach es schnell um jeden Preis“. Es ist eine disziplinierte Schleife:

• entscheide, was „schnell genug“ heißt
• miss, wohin die Zeit tatsächlich geht
• ändere eine Sache mit Absicht
• verifiziere, dass du die richtige Metrik verbessert hast

Diese Denkweise taucht in Carmacks Arbeit immer wieder auf: mit Daten streiten, Änderungen erklärbar halten und Ansätze bevorzugen, die wartbar sind.

Warum Echtzeitgrafik die Realität offenlegt

Echtzeitgrafik ist unforgiving, weil sie für jedes Frame eine Deadline hat. Wenn du sie verfehlst, merkt der Nutzer es sofort als Ruckeln, Eingabeverzögerung oder ungleichmäßige Bewegung. Andere Software kann Ineffizienz hinter Queues, Ladebildschirmen oder Hintergrundarbeit verstecken. Ein Renderer kann nicht verhandeln: entweder du bist rechtzeitig fertig, oder nicht.

Deshalb verallgemeinern die Lektionen über Spiele hinaus. Jedes System mit strikten Latenzanforderungen – UI, Audio, AR/VR, Trading, Robotik – profitiert davon, in Budgets zu denken, Engpässe zu verstehen und Überraschungsspitzen zu vermeiden.

Was du mitnimmst

Du bekommst Checklisten, Heuristiken und Entscheidungs­muster, die du auf deine Arbeit anwenden kannst: wie man Frame‑Zeit‑/Latenz‑Budgets setzt, wie man vor dem Optimieren profilt, wie man die „eine Sache“ auswählt, die zu fixen ist, und wie man Regressionen verhindert, damit Performance Routine wird – nicht ein panischer Endspurt.

Denk in Frame‑Zeit‑Budgets, nicht nach Gefühlen

Carmack‑ähnliches Performance‑Denken beginnt mit einem einfachen Schalter: Hör auf, über „FPS“ als primäre Einheit zu reden und fang an, über Frame‑Zeit zu sprechen.

FPS ist reziprok („60 FPS“ klingt gut, „55 FPS“ klingt nah), aber die Nutzererfahrung wird von wie lange jedes Frame dauert bestimmt – und ebenso wichtig, wie konsistent diese Zeiten sind. Ein Sprung von 16,6 ms auf 33,3 ms ist sofort sichtbar, auch wenn dein durchschnittlicher FPS‑Wert noch respektabel aussieht.

Frame‑Zeit vs. FPS (warum Frame‑Zeit gewinnt)

• FPS verschleiert Variabilität. Zwei Builds können beide „im Schnitt 60 FPS“ haben, aber eines stottert wegen gelegentlicher 40–60‑ms‑Frames.
• Frame‑Zeit bildet Arbeit ab. Jede Millisekunde ist ein realer Teil von CPU/GPU‑Arbeit, den du Systemen zuordnen kannst.
• Ziele sind klarer. „Unter 16,6 ms bleiben“ ist eine konkrete Anforderung; „sich flüssig anfühlen“ ist es nicht.

Budgets: Wofür du wirklich zahlst

Ein Echtzeitprodukt hat mehrere Budgets, nicht nur „rendern schneller“:

• CPU‑Zeit (Spiel‑Logik, Animation, Culling, Draw‑Call‑Submission)
• GPU‑Zeit (Shading, Post‑Processing, Overdraw, Auflösung)
• Speicher (Footprint, Spitzen, Fragmentierung, Streaming‑Headroom)
• Ladezeit (Boot, Level‑Laden, Shader‑Kompilierung, Streaming‑Stalls)

Diese Budgets interagieren. GPU‑Zeit durch CPU‑starkes Batching zu sparen kann schiefgehen, und weniger Speicher kann Streaming‑ oder Dekompressionskosten erhöhen.

Beispiel: 16,6 ms bei 60 FPS

Wenn dein Ziel 60 FPS ist, ist dein Gesamtbudget 16,6 ms pro Frame. Eine grobe Aufteilung könnte so aussehen:

• CPU: 7 ms (Simulation, Gameplay, Visibility)
• GPU: 9 ms (Render + Post)
• OS/Treiber + Overhead‑Puffer: ~0,6 ms

Wenn entweder CPU oder GPU das Budget überschreitet, verpasst du das Frame. Deshalb reden Teams darüber, „CPU‑bound“ oder „GPU‑bound“ zu sein – nicht als Etikett, sondern als Weg, zu entscheiden, wo das nächste Millisekunden‑Gewinn realistisch herkommen kann.

„Schnell genug“ ist eine Produktanforderung

Der Punkt ist nicht, einer Eitelkeitsmetrik wie „höchste FPS auf einer High‑End‑Kiste“ hinterherzulaufen. Der Punkt ist, zu definieren, was schnell genug für deine Zielgruppe ist – Hardwareziele, Auflösung, Akku‑Limits, Thermik und Eingabereaktivität – und Performance dann als explizite Budgets zu behandeln, die du verwalten und verteidigen kannst.

Erst Profiling: Messen, dann entscheiden

Carmacks Standardzug ist nicht „optimieren“, sondern „verifizieren“. Echtzeit‑Performanceprobleme strotzen vor einleuchtenden Geschichten – GC‑Pauses, „langsame Shader“, „zu viele Draw Calls“ – und die meisten davon sind in deinem Build auf deiner Hardware falsch. Profiling ersetzt Intuition durch Evidenz.

Fang mit Messen an (bevor du rätst)

Behandle Profiling wie eine erstklassige Funktion, nicht als Rettungswerkzeug in letzter Minute. Erfasse Frame‑Zeiten, CPU‑ und GPU‑Timelines und die Zähler, die sie erklären (Dreiecke, Draw Calls, Zustandwechsel, Allokationen, Cache‑Misses, wenn du sie bekommst). Das Ziel ist, eine Frage zu beantworten: Wohin geht die Zeit wirklich?

Ein nützliches Modell: In jedem langsamen Frame ist eine Sache der begrenzende Faktor. Vielleicht ist die GPU in einem schweren Pass blockiert, die CPU in der Animations‑Update‑Phase oder der Main‑Thread an Synchronisationen fest. Finde diese Einschränkung zuerst; alles andere ist Rauschen.

Iteriere wie ein Wissenschaftler

Eine disziplinierte Schleife verhindert Thrash:

• Miss eine Basislinie mit einer reproduzierbaren Szene und Kamerafahrt
• Ändere eine Sache
• Messe erneut und schreibe das Delta auf

Wenn die Verbesserung nicht klar ist, nimm an, dass sie nicht geholfen hat – weil sie wahrscheinlich nicht stabil genug für nächsten Content ist.

Vorsicht vor Placebo‑Optimierungen

Performance‑Arbeit ist besonders anfällig für Selbsttäuschung:

• Benchmark‑Fehler: inkonsistente Testszene, Debug‑Builds, Hintergrundprozesse, thermisches Throttling, VSync‑Unterschiede
• Bestätigungsfehler: „es fühlt sich schneller an“ ohne Frame‑Zeit‑Daten
• Irreführende Durchschnitte: ein besserer Mittelwert kann schlechtere Spitzen verbergen

Profiling zuerst hält den Aufwand fokussiert, begründet die Trade‑offs und macht Änderungen in Reviews leichter zu verteidigen.

Engpässe: Finde die eine Sache, die tatsächlich langsam ist

Echtzeit‑Performanceprobleme wirken chaotisch, weil alles gleichzeitig passiert: Gameplay, Rendering, Streaming, Animation, UI, Physik. Carmacks Instinkt ist, das Rauschen zu durchschneiden und den dominanten Limiter zu identifizieren – die eine Sache, die gerade deine Frame‑Zeit setzt.

Häufige Engpass‑Kategorien

Die meisten Verlangsamungen fallen in ein paar Buckets:

• CPU‑bound: der Main‑Thread (oder ein kritischer Worker) schafft seine Arbeit nicht rechtzeitig – Spiel‑Logik, Draw‑Call‑Submission, Physik, Animation.
• GPU‑bound: die GPU schafft das Frame nicht – schwere Shader, zu viele Pixel, teures Post‑Processing, komplexe Geometrie.
• Memory‑bound: begrenzt durch Bandbreite/Latenz – Cache‑Misses, schlechte Datenlayout, viel Random‑Access, große Buffer‑Kopien.
• I/O‑bound: Asset‑Streaming, Shader‑Kompilierung, Dekompression, Datei‑Reads, Netzwerk‑Wartezeiten.

Der Punkt ist nicht das Label für einen Report, sondern den richtigen Hebel zu wählen.

Schnelle Diagnose‑Methoden (bevor du umschreibst)

Ein paar schnelle Experimente können dir sagen, was wirklich kontrolliert:

• Auflösungs‑Scaling‑Test: reduziere die Renderauflösung (oder zwinge dynamische Auflösung). Wenn die Frame‑Zeit stark besser wird, bist du wahrscheinlich GPU/pixel‑limitiert. Bewegt sich kaum etwas, sieh dir CPU oder nicht‑pixel GPU‑Arbeit an.
• Feature‑Toggles: schalte Schatten, SSR, AO, Partikel oder teure Pässe einzeln aus. Eine spürbare Änderung zeigt, wo die Zeit hingeht.
• Instrumentation und Captures: nutze eingebaute Timer, einen CPU‑Profiler und einen GPU‑Capture, um zu sehen, wo die Millisekunden landen.

Das „ein großer Stein“‑Prinzip

Man gewinnt selten, indem man 1% an zehn Systemen abschabt. Finde die größte wiederkehrende Kostenstelle und attackiere sie zuerst. Einen einzelnen 4‑ms‑Verursacher zu entfernen schlägt Wochen an Mikrooptimierungen.

Engpässe wandern

Nachdem du den großen Stein entfernt hast, wird der nächste sichtbare Stein offenbar. Das ist normal. Behandle Performance‑Arbeit als Schleife: messen → ändern → neu messen → neu priorisieren. Das Ziel ist nicht ein perfektes Profil; es ist stetiger Fortschritt zu vorhersehbarer Frame‑Zeit.

Glätte gewinnt: Spikes, Stottern und Tail‑Latency

Durchschnittliche Frame‑Zeit kann gut aussehen, während die Erfahrung sich trotzdem schlecht anfühlt. Echtzeitgrafik wird an den schlimmsten Momenten gemessen: dem ausgelassenen Frame bei einer großen Explosion, dem Hänger beim Betreten eines neuen Raums, dem plötzlichen Stottern beim Öffnen eines Menüs. Das ist Tail‑Latency – seltene, aber spürbare langsame Frames.

Warum Tails wichtiger sind als Durchschnitte

Ein Spiel, das die meiste Zeit bei 16,6 ms (60 FPS) läuft, aber alle paar Sekunden auf 60–120 ms spike't, fühlt sich „kaputt“ an, selbst wenn der Durchschnitt 20 ms bleibt. Menschen sind empfindlich gegenüber Rhythmus. Ein langer Frame zerstört Eingabevorhersagbarkeit, Kamerabewegung und Audio/Video‑Sync.

Häufige Ursachen für Spikes

Spikes entstehen oft durch Arbeit, die nicht gleichmäßig verteilt ist:

• Garbage Collection oder Page‑Faults, die die Welt anhalten
• Shader‑Kompilierung und Pipelineerstellung, die „just in time“ ausgelöst werden
• Asset‑Streaming, das spontan Dekompression, Uploads oder Datei‑I/O benötigt
• OS‑Scheduling und Hintergrundarbeit, die CPU‑Zeit stiehlt (oder Frequenz/Thermik ändert)

Strategien, Stottern zu reduzieren

Das Ziel ist, teure Arbeit vorhersehbar zu machen:

• Vorberechnen wo möglich: Shader offline bauen, Daten backen, Lookup‑Tabellen vorbereiten.
• Aufwärmen früh: Shaders kompilieren, Pipelines erstellen, kritische Assets während Ladebildschirmen oder einer kontrollierten Aufwärmszene touchen.
• Amortisieren teurer Tasks: Streaming, Dekompression und Uploads über viele Frames verteilen anstatt in einem.
• Arbeit pro Frame begrenzen: Zeitbudgets durchsetzen (z. B. „nicht mehr als 2 ms fürs Streaming dieses Frame“) und den Rest verschieben.

Logge und visualisiere die Tail

Plotte nicht nur eine Average‑FPS‑Kurve. Erfasse Per‑Frame‑Timings und visualisiere:

• Histogramme der Frame‑Zeit, um Cluster und Ausreißer zu sehen
• Perzentile (p95, p99, p99.9) zur expliziten Verfolgung der Tail
• Spike‑Marker mit korrelierten Ereignissen (GC‑Start, Shader‑Kompilierung, Asset‑Load)

Wenn du die schlimmsten 1% deiner Frames nicht erklären kannst, hast du Leistung nicht wirklich verstanden.

Mach Trade‑offs explizit (Qualität vs. Geschwindigkeit vs. Komplexität)

Performance‑Arbeit wird leichter, sobald du aufhörst so zu tun, als könntest du alles gleichzeitig haben. Carmacks Stil drängt Teams dazu, den Tradeoff offen zu benennen: Was kaufen wir, was zahlen wir, und wer merkt den Unterschied?

Benenne die Achsen (und die realen Kosten)

Die meisten Entscheidungen liegen auf ein paar Achsen:

• Qualität: visuelle Treue, Simulationsgenauigkeit, Eingabefühl
• Geschwindigkeit: Frame‑Zeit, Ladezeit, Kompilierzeit, Iterationszeit
• Speicher: VRAM, RAM, Bandbreite
• Komplexität: schwierigeres Debugging, mehr Edge‑Cases, mehr Testaufwand
• Time‑to‑Ship: Terminrisiko, Integrationsrisiko, Teamfokus

Wenn eine Änderung eine Achse verbessert, aber drei andere heimlich belastet, dokumentiere das. „Das fügt 0,4 ms GPU und 80 MB VRAM hinzu, um weichere Schatten zu bekommen“ ist eine brauchbare Aussage. „Sieht besser aus“ ist es nicht.

Definiere „gut genug“‑Schwellen

Echtzeitgrafik geht nicht um Perfektion; es geht darum, ein Ziel konsistent zu erreichen. Einigt euch auf Schwellen wie:

• minimale FPS / maximale Frame‑Zeit auf einer Referenzmaschine
• akzeptable Worst‑Case‑Spikes (nicht nur Durchschnitt)
• Speicherobergrenzen pro Plattform

Sobald das Team z. B. 16,6 ms bei 1080p auf der Baseline‑GPU als Ziel hat, werden Argumente konkret: Hält dieses Feature uns unter Budget oder erzwingt es Abstriche anderswo?

Bevorzuge reversible Entscheidungen

Wenn du unsicher bist, wähle Optionen, die rückgängig zu machen sind:

• Feature‑Flags für riskante Effekte
• Skalierbare Einstellungen (low/medium/high), die in echte Kosten übersetzt werden
• Fallback‑Pfade für ältere Hardware

Reversibilität schützt den Zeitplan. Du kannst den sicheren Pfad ausliefern und den ambitionierten hinter einem Schalter lassen.

Optimiere, was Nutzer fühlen können

Vermeide Überengineering für unsichtbare Verbesserungen. Eine 1%‑Durchschnittsverbesserung ist selten einen Monat Komplexität wert – es sei denn, sie beseitigt Stottern, reduziert Eingabelatenz oder verhindert einen harten Speichercrash. Priorisiere Änderungen, die Spieler sofort merken, und lass den Rest warten.

Engineering‑Disziplin: Korrektheit ermöglicht Geschwindigkeit

Performance‑Arbeit wird dramatisch einfacher, wenn das Programm richtig ist. Eine überraschende Menge „Optimierungszeit“ wird tatsächlich damit verbracht, Korrektheitsfehler nachzujagen, die nur wie Performance‑Probleme aussehen: eine versehentliche O(N²)‑Schleife durch duplizierte Arbeit, ein Renderpass, der zweimal läuft weil ein Flag nicht zurückgesetzt wurde, ein Memory‑Leak, das die Frame‑Zeit langsam erhöht, oder eine Race‑Condition, die zufälliges Stottern erzeugt.

Behandle Korrektheit als Performance‑Werkzeug

Eine stabile, vorhersehbare Engine liefert saubere Messungen. Wenn sich das Verhalten zwischen Läufen ändert, kannst du Profiling nicht vertrauen und optimierst Rauschen.

Disziplinierte Engineering‑Praktiken helfen bei der Geschwindigkeit:

• Klare Invarianten: definiere, was immer wahr sein muss (z. B. „jedes sichtbare Objekt wird einmal submit­tet“, „GPU‑Ressourcen werden nicht verändert, während sie in‑flight sind“, „Frame‑Graph hat keine Zyklen“).
• Validierung in Debug‑Builds: füge Assertions und leichte Checks hinzu, die früh schreien – bevor ein gebrochener Zustand in mysteriöses Hitchen umschlägt. Validier Buffer‑Größen, Zustandsübergänge und dass per‑Frame‑Allokationen unter einem bekannten Limit bleiben.

Mach Performance‑Bugs reproduzierbar auf Knopfdruck

Viele Frame‑Time‑Spikes sind „Heisenbugs“: sie verschwinden, wenn du Logging einbaust oder im Debugger stepst. Das Gegenmittel ist deterministische Reproduktion.

Baue ein kleines, kontrolliertes Test‑Harness:

• Minimale Test‑Szenen, die ein Feature isolieren (Shadows, Particles, UI, Streaming)
• Feste Kamerapfade und skriptierte Eingabe, sodass jeder Lauf vergleichbar ist
• Gesperrte Einstellungen (Auflösung, Qualitätslevel, fixierter Time‑Step wenn möglich), um Variablen zu entfernen

Wenn ein Hänger auftaucht, willst du einen Button, der ihn 100 Mal abspielt – nicht einen vagen Report, dass er „manchmal nach 10 Minuten“ passiert.

Weniger ändern, mehr lernen

Speed‑Arbeit profitiert von kleinen, reviewbaren Änderungen. Große Refactors schaffen mehrere Fehlerquellen auf einmal: Regressionen, neue Allokationen und versteckte Mehrarbeit. Enge Diffs machen es einfacher, die einzige Frage zu beantworten, die zählt: Was hat sich an der Frame‑Zeit geändert und warum?

Disziplin ist hier keine Bürokratie – sie ist, wie du Messungen vertrauenswürdig hältst, sodass Optimierung klar statt abergläubisch wird.

Arbeite mit der Maschine: Daten, Cache und Overhead

Echtzeit‑Performance ist nicht nur „schneller Code“. Es geht darum, Arbeit so zu arrangieren, dass CPU und GPU sie effizient erledigen können. Carmack betonte immer wieder eine einfache Wahrheit: die Maschine ist literal. Sie liebt vorhersehbare Daten und hasst vermeidbaren Overhead.

Datenorientiertes Denken: Mach Speicher leicht lesbar

Moderne CPUs sind unglaublich schnell – bis sie auf Speicher warten. Wenn deine Daten über viele kleine Objekte verstreut sind, rennt die CPU Zeiger nach, statt Rechnungen zu machen.

Ein nützliches Bild: Mach nicht zehn kleine Einkaufstouren für zehn Artikel. Pack sie in einen Wagen und geh einmal durch die Gänge. Im Code heißt das, häufig genutzte Werte nahe beieinander zu halten (oft in Arrays oder dicht gepackten Structs), damit jede Cache‑Line nützliche Daten bringt.

Allokationsmuster: kleiner Churn wird großes Leid

Häufige Allokationen erzeugen versteckte Kosten: Allocator‑Overhead, Speicherfragmentierung und unvorhersehbare Pausen, wenn das System aufräumt. Auch wenn jede Allokation „klein“ ist, kann ein stetiger Strom von ihnen zu einer Steuer werden, die du jedes Frame zahlst.

Gängige Fixes sind absichtlich langweilig: Puffer wiederverwenden, Objekte poolen und langfristige Allokationen für heiße Pfade bevorzugen. Das Ziel ist Konsistenz, nicht Cleverness.

Batching: reduziere Overhead bevor du Math optimierst

Eine überraschende Menge Frame‑Zeit verschwindet in Buchhaltung: Zustandwechsel, Draw Calls, Treiberarbeit, Syscalls und Thread‑Koordination.

Batching ist die „große Einkaufstasche“ des Renderings und der Simulation. Statt vieler kleiner Operationen gruppiere ähnliche Arbeit, damit du teure Grenzen seltener überschreitest. Oft schlägt das Reduzieren von Overhead das Mikro‑Optimieren eines Shaders oder einer inneren Schleife – denn die Maschine verbringt weniger Zeit damit, sich vorzubereiten, und mehr Zeit damit, zu arbeiten.

Einfachheit als Performance‑Strategie

Performance‑Arbeit ist nicht nur schneller Code – es geht auch darum, weniger Code zu haben. Komplexität kostet jeden Tag: Bugs brauchen länger zum Isolieren, Fixes erfordern mehr Tests, Iteration verlangsamt sich, weil jede Änderung mehr Teile berührt, und Regressionen schleichen sich über selten genutzte Pfade ein. Diese Komplexität verschwendet nicht nur Entwicklerzeit; sie fügt oft Laufzeit‑Overhead hinzu (zusätzliche Branches, Allokationen, Cache‑Misses, Synchronisation), der schwer sichtbar ist, bis es zu spät ist.

Die versteckte Steuer der Komplexität

Ein „cleveres“ System kann elegant wirken, bis du auf Deadline ein Frame‑Spike hast, das nur auf einer Map, einer GPU oder einer Einstellungen‑Kombination auftritt. Jedes zusätzliche Feature‑Flag, jeder Fallback und jeder Spezialfall vervielfacht die Verhaltensweisen, die du verstehen und messen musst. Diese Komplexität verschwendet nicht nur Entwicklungszeit; sie fügt oft Laufzeitkosten hinzu, die schwer zu sehen sind.

Bevorzuge Lösungen, die du erklären kannst

Eine gute Regel: Wenn du das Performance‑Modell nicht in ein paar Sätzen einem Teamkollegen erklären kannst, kannst du es wahrscheinlich nicht zuverlässig optimieren.

Einfache Lösungen haben zwei Vorteile:

• Sie sind leichter zu profilieren und zu durchschauen (weniger Variablen)
• Sie reduzieren „unknown unknowns“, bei denen eine kleine Änderung unvorhergesehene Verlangsamungen verursacht

„Code löschen" ist ein echtes Optimierungswerkzeug

Manchmal ist der schnellste Weg, ein Feature zu entfernen, eine Option zu streichen oder Varianten zu konsolidieren. Weniger Features heißt weniger Codepfade, weniger Zustandskombinationen und weniger Orte, an denen Performance stillschweigend schlechter werden kann.

Code zu löschen ist auch eine Qualitätsmaßnahme: der beste Bug ist der, den du gar nicht mehr haben kannst, weil das Modul entfernt wurde.

Refactor oder Patch? Eine kurze Entscheidungs‑Checkliste

Patch (surgische Korrektur), wenn:

• du einen spezifischen Hot‑Path identifiziert hast und eine kleine Änderung ihn messbar verbessert
• das System stabil und weit verbreitet ist; Architekturänderungen riskieren neue Regressionen
• du eine sichere Verbesserung brauchst, die in den aktuellen Release‑Zeitplan passt

Refactor (Struktur vereinfachen), wenn:

• Profiling zeigt Overhead über viele Call‑Sites oder Schichten verteilt
• du wiederholt die Performance in demselben Bereich nach unzusammenhängenden Änderungen brichst
• der Code tribal knowledge braucht, um sicher zu ändern
• du Pfade löschen oder zusammenlegen kannst und am Ende weniger Konzepte übrig bleiben

Einfachheit ist nicht „weniger ambitioniert“. Es ist die Wahl von Designs, die unter Druck verständlich bleiben – wenn Performance am wichtigsten ist.

Verhindere Regressionen: Mach Performance zur Gewohnheit

Performance‑Arbeit bleibt nur, wenn du merkst, wann sie nachlässt. Genau das ist Performance‑Regressionstesting: eine reproduzierbare Methode, um zu erkennen, wann eine Änderung das Produkt langsamer, weniger flüssig oder speicherhungriger macht. Im Gegensatz zu Funktionstests („funktioniert es?“) beantworten Regressionstests „fühlt es sich noch gleich schnell an?" Ein Build kann 100% korrekt sein und trotzdem ein schlechter Release, wenn er 4 ms Frame‑Zeit hinzufügt oder Ladezeiten verdoppelt.

Ein leichter Workflow, der wirklich genutzt wird

Du brauchst kein Labor, um anzufangen – nur Konsistenz.

Wähle einen kleinen Satz Baseline‑Szenen, die reale Nutzung repräsentieren: eine GPU‑schwere Ansicht, eine CPU‑schwere Ansicht und eine „Worst‑Case“‑Stressszene. Halte sie stabil und skriptiert, sodass Kamerapfad und Eingaben bei jedem Lauf identisch sind.

Führe Tests auf fester Hardware (bekannter PC/Console/Devkit) aus. Wenn du Treiber, OS oder Takteinstellungen änderst, notiere es. Behandle die Hardware/Software‑Kombination als Teil des Test‑Fixtures.

Speichere Ergebnisse in einer versionierten Historie: Commit‑Hash, Build‑Config, Maschinen‑ID und gemessene Metriken. Das Ziel ist keine perfekte Zahl, sondern eine vertrauenswürdige Trendlinie.

CI‑freundliche Metriken zum Tracken

Bevorzuge schwer zu bestreitende Metriken:

• Frame‑Zeit‑Perzentile (p50/p95/p99), nicht nur average FPS. Perzentile zeigen Stottern und Long‑Tail‑Hitches.
• Peak‑Memory (und Allokationsspitzen). Memory‑Creep zeigt sich oft bevor Abstürze folgen.
• Ladezeit (Cold‑Start und Level/Scene‑Transitions), weil Spieler Sekunden mehr wahrnehmen als Mikro‑Optimierungen.

Definiere einfache Schwellen (z. B. p95 Frame‑Time darf nicht um mehr als 5% regressieren).

Was tun, wenn du eine Regression findest

Behandle Regressionen wie Bugs mit Owner und Deadline.

Zuerst bisecten, um die Änderung zu finden, die sie eingeführt hat. Wenn die Regression einen Release blockiert, reverte schnell und lande die Änderung mit Fix neu.

Wenn du sie behoben hast, füge Guardrails hinzu: behalte den Test, füge eine Notiz im Code hinzu und dokumentiere das erwartete Budget. Die Gewohnheit ist der Gewinn – Performance wird etwas, das du erhältst, nicht etwas, das du „später machst."

Komplexe Systeme ausliefern: Performance, Deadlines und Realität

„Shippen“ ist kein Kalenderevent – es ist eine technische Anforderung. Ein System, das nur im Labor gut läuft oder erst nach einer Woche manuellen Tweakings die Frame‑Zeit erreicht, ist nicht fertig. Carmacks Denkweise behandelt reale Beschränkungen (Hardware‑Vielfalt, unordentlicher Content, unvorhersehbares Spieler‑Verhalten) von Tag eins als Teil der Spezifikation.

Shippen heißt entscheiden, was wahr sein muss

Wenn du nah an Release bist, ist Vorhersehbarkeit wertvoller als Perfektion. Definiere die Non‑Negotiables klar: Ziel‑FPS, Worst‑Case‑Frame‑Time‑Spikes, Speicherlimits, Ladezeiten. Behandle alles, was sie verletzt, als Bug, nicht als „Polish“. Das rückt Performance‑Arbeit von optionaler Optimierung zu Zuverlässigkeitsarbeit.

Priorisiere, was Spieler wirklich fühlen

Nicht alle Verlangsamungen sind gleich wichtig. Behebe zuerst die sichtbarsten Probleme:

• Stottern und lange Spikes schlagen meist konstant‑etwas‑langsamere Darstellung in wahrgenommener Qualität.
• Menü‑Hänger, Streaming‑Pops und Eingabelatenz schaden der Erfahrung oft mehr als ein kleiner Verlust beim durchschnittlichen FPS.
• Regressionen in gängigen Szenarien (viel Combat, Kameradrehungen, effektreiche Momente) verdienen Vorrang vor seltenen Eckfällen.

Profiling‑Disziplin zahlt sich aus: du rätst nicht, welches Problem „groß“ scheint, sondern wählst basierend auf gemessenem Impact.

Änderungen staffeln und auf Sicherheit setzen

Spätere Performance‑Arbeit ist riskant, weil „Fixes" neue Kosten einführen können. Nutze gestufte Rollouts: land Instrumentation zuerst, dann die Änderung hinter einem Toggle, dann weite Exposure. Bevorzuge performance‑sichere Defaults – Einstellungen, die Frame‑Zeit schützen, auch wenn sie die visuelle Qualität leicht reduzieren – besonders bei autodetektierten Konfigurationen.

Wenn du mehrere Plattformen/Tiers auslieferst, betrachte Defaults als Produktentscheidung: Es ist besser, etwas weniger fancy auszusehen, als instabil zu wirken.

Kommuniziere Beschränkungen an Nicht‑Techniker

Übersetze Tradeoffs in Outcomes: „Dieser Effekt kostet 2 ms jedes Frame auf Mittelklasse‑GPUs, was uns in Kämpfen unter 60 FPS bringen könnte.“ Biete Optionen, keine Vorträge: Auflösung reduzieren, Shader vereinfachen, Spawn‑Rate limitieren oder ein niedrigeres Ziel akzeptieren. Beschränkungen sind leichter akzeptierbar, wenn sie als konkrete Entscheidungen mit klarem Nutzerimpact präsentiert werden.

Eine praktische Checkliste, um die Denkweise heute anzuwenden

Du brauchst keine neue Engine oder einen Rewrite, um Carmack‑ähnliches Performance‑Denken zu übernehmen. Du brauchst eine wiederholbare Schleife, die Performance sichtbar, testbar und schwer versehentlich zu brechen macht.

Die wiederholbare Schleife (messen → budgetieren → isolieren → optimieren → validieren → dokumentieren)

1. Messen: erfasse eine Basislinie (Durchschnitt, p95, schlimmster Spike) für Frame‑Zeit und Schlüssel‑Subsysteme.

2. Budgetieren: setze ein Per‑Frame‑Budget für CPU und GPU (und Speicher, wenn knapp). Schreibe das Budget neben das Feature‑Ziel.

3. Isolieren: reproduziere die Kosten in einer minimalen Szene oder einem Test. Wenn du es nicht reproduzieren kannst, kannst du es nicht zuverlässig fixen.

4. Optimieren: ändere eine Sache zur Zeit. Bevorzuge Änderungen, die Arbeit reduzieren, nicht nur „schneller machen".

5. Validieren: profiliere erneut, vergleiche Deltas und prüfe auf Qualitäts‑ oder Korrektheitsregressionen.

6. Dokumentieren: notiere, was sich geändert hat, warum es geholfen hat und worauf in Zukunft zu achten ist.

Faustregeln, die du sofort anwenden kannst

• Optimiere die größte Anzeige, nicht die nervigste Vermutung.
• Jage Spikes vor Durchschnitten, wenn Nutzer Stottern fühlen.
• Wenn du die Kosten nicht erklären kannst, besitzt du das Feature noch nicht.
• Bevorzuge vorhersehbare Kosten gegenüber seltenen Worst‑Case‑Explosionen.
• Budgetiere neue Arbeit im Voraus (CPU ms, GPU ms, Speicher, Bandbreite).
• Vermeide versteckte per‑Object/per‑Frame‑Schleifen, die mit Content skalieren.
• **Mach Performance‑Tests zum Teil von „done"