Python-JIT: Leistungsgewinn reicht noch nicht für Support

CPythons experimenteller Just-in-Time-Compiler liefert in Benchmarks messbare Leistungsgewinne. Trotzdem hat das Python Steering Council am 5. Juni 2026 beschlossen, neue JIT-Funktionen im Hauptzweig vorerst nicht weiter aufzunehmen. Bis Dezember 2026 muss ein Standards-Track-PEP eingereicht und genehmigt sein. Andernfalls soll der JIT-Code aus dem Hauptzweig entfernt werden.

Für Unternehmen, die Python betreiben, ist diese Unterscheidung wichtig: Ein experimenteller Beschleuniger gehört damit noch nicht zur dauerhaft zugesicherten Ausstattung der Laufzeitumgebung. Wer Kapazitäten plant oder einen Versionswechsel wirtschaftlich begründet, sollte seine Rechnung vorerst ohne diesen Zusatzgewinn aufstellen. Die Entscheidung betrifft den Übergang vom Experiment zur unterstützten Kernkomponente.

Die Pause ist keine bereits vollzogene Entfernung

Der Entwicklungsstopp bezieht sich auf neue JIT-Funktionen im CPython-Hauptzweig. Daraus folgt weder, dass der Compiler bereits entfernt wurde, noch dass Python seine Arbeit an höherer Ausführungsgeschwindigkeit insgesamt eingestellt hat. Auch die Dezemberfrist ist zunächst eine Bedingung für den weiteren Verbleib des Codes.

Als Antwort wurde im Juli 2026 PEP 836 eingereicht. Der Vorschlag mit dem Titel „JIT Go Brrr: The Path to a Supported JIT Compiler for CPython“ soll den verlangten Fahrplan liefern. Eine Einreichung erfüllt allerdings nur einen Teil der Anforderung: Das Steering Council verlangt auch die Genehmigung. Aus dem Vorliegen des Vorschlags allein lässt sich deshalb keine gesicherte Zukunft des JIT ableiten.

Die bisherige Grundlage ist PEP 744. Darüber kam der Compiler mit Python 3.13 als experimentelle, standardmäßig deaktivierte Funktion in CPython. Dieses PEP ist als „Informational“ eingeordnet. Für die dauerhafte Unterstützung verlangt das Steering Council nun einen Standards-Track-Prozess, in dem der weitere Weg ausdrücklich beschlossen wird.

Zwischen Benchmark und unterstützter Funktion

Für die 3.15-Entwicklung werden mit JIT geometrisch gemittelte Verbesserungen von 8 bis 9 Prozent auf x86-64 unter Linux und 12 bis 13 Prozent auf Apple Silicon genannt. Das Ziel für eine offizielle Unterstützung liegt bei mindestens 20 Prozent gegenüber dem Standard-Interpreter.

Damit besteht noch Abstand zur Zielmarke. Zudem sind geometrische Mittelwerte keine Zusage für einzelne Anwendungen. Sie verdichten die Ergebnisse mehrerer Tests zu einer Kennzahl. Aus einem solchen Wert lässt sich nicht ableiten, dass ein bestimmter Webdienst entsprechend weniger Rechenzeit benötigt oder ein Datenverarbeitungsauftrag um denselben Anteil früher fertig wird.

Ein JIT übersetzt häufig ausgeführten Code während der Laufzeit in Maschinencode. Wie viel das bringt, hängt davon ab, wo eine Anwendung ihre Zeit verbringt. Wartet ein Dienst überwiegend auf Datenbankantworten oder Netzwerkzugriffe, verkürzt eine schnellere Python-Ausführung diese Wartezeiten nicht. Auch Arbeit, die bereits in nativen Bibliotheken erledigt wird, ist nicht automatisch im gleichen Umfang beschleunigbar.

Für eine belastbare Kostenrechnung wären deshalb Messungen mit der eigenen Anwendung nötig. Dazu gehören neben der Laufzeit auch Startverhalten und Speicherbedarf. Die genannten Prozentwerte begründen weitere Tests; eine pauschale Senkung des Infrastrukturbedarfs begründen sie nicht.

Wartung wird zur Voraussetzung

Ein dauerhaft unterstützter Compiler erweitert die Aufgaben im Kernprojekt. Änderungen am Interpreter müssen mit ihm zusammenpassen, Fehler müssen reproduzierbar sein, und die unterstützten Plattformen benötigen verlässliche Tests. Diese Arbeit fällt auch dann an, wenn gerade keine zusätzliche Beschleunigung erreicht wird.

Hier bekommt die Finanzierung praktische Relevanz. Das Ende der Microsoft-Finanzierung für das Faster-CPython-Team hat die JIT-Entwicklung nach Angaben aus dem Projekt belastet; die Arbeit wurde auf freiwilliger Basis fortgeführt. Das erklärt nicht jede technische Schwierigkeit. Es verändert aber die verfügbare Arbeitskapazität für Entwicklung, Prüfung und Wartung.

Ein genehmigtes PEP ersetzt diese Kapazität nicht. Es kann jedoch festhalten, welche Ziele erreicht werden sollen und unter welchen Bedingungen das Projekt eine Funktion dauerhaft unterstützt. Für Anwender ist das ein wesentlicher Unterschied: Ein erfolgreicher Versuch zeigt technische Möglichkeiten. Eine unterstützte Funktion benötigt zusätzlich einen tragfähigen Betrieb über mehrere Python-Versionen hinweg.

Was Betreiber jetzt einplanen können

Für gewöhnliche CPython-Installationen ist die unmittelbare Auswirkung begrenzt. Der JIT ist seit seiner Einführung experimentell und standardmäßig deaktiviert. Wer ihn nicht ausdrücklich nutzt, muss wegen des Entwicklungsstopps keine bestehende JIT-Konfiguration ersetzen.

Unabhängig davon bleibt der adaptive, spezialisierende Interpreter aus PEP 659 relevant. Er ist seit Python 3.11 Bestandteil von CPython und benötigt keine gesonderte JIT-Aktivierung. Die Auseinandersetzung um den zusätzlichen Compiler sollte daher nicht mit einem Stillstand sämtlicher Performance-Arbeit verwechselt werden.

Für Teams mit eigenen JIT-Versuchen empfiehlt sich eine getrennte Bewertung: Die Anwendung muss ohne den experimentellen Compiler ausreichend funktionieren; mögliche Zusatzgewinne werden separat gemessen. Damit bleibt ein Versionswechsel auch dann kalkulierbar, wenn sich der Status des JIT ändert.

Der nächste belastbare Schritt ist die Genehmigung eines verbindlichen Entwicklungsplans. Bis dahin bleibt der native JIT eine experimentelle Option. Seine bisherigen Leistungswerte rechtfertigen die Weiterentwicklung, reichen aber noch nicht aus, um ihn als feste Grundlage für Betriebs- und Kapazitätsplanung zu behandeln.