Das Team hinter dem Open-Source-Framework Reflex hat seinen Python-Linter um den Faktor 220 beschleunigt, indem es eine einzige Standardfunktion ersetzte. Der Engpass saß nicht im eigenen Code, sondern in ast.walk aus der Python-Standardbibliothek.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Bei der Verarbeitung großer Mengen generierten Codes wurde das Durchlaufen des Syntaxbaums zur Bremse. Die Lösung zeigt, wie viel Tempo in einer scheinbar harmlosen Hilfsfunktion stecken kann.
Das Wichtigste in Kürze
- Reflex generiert in seinem KI-App-Builder große Mengen Python-Code und prüft ihn mit einem eigenen Linter.
- Der langsamste Teil war nicht die Typprüfung, sondern
ast.walkbeim Durchlaufen des Syntaxbaums. - Durch das Scannen nur der vorab bekannten Feld-Einträge im Knoten erreicht das Team rund 99,5 Prozent Ersparnis, also etwa eine 220-fache Beschleunigung.
- Das Open-Source-Projekt fast-walk treibt den Ansatz mit gebündeltem Prefetching noch weiter.
Warum bremst eine Standardfunktion den ganzen Linter aus?
Reflex erzeugt im KI-App-Builder automatisch Python-Code, und dieser Code enthält regelmäßig triviale Fehler wie Positionsargumente nach Keyword-Argumenten oder veraltete Syntax. Ein voller Compile-Lauf findet immer nur einen Fehler nach dem anderen, was die Latenz bei mehreren Fehlern stark erhöht. Ein Linter prüft alles auf einmal, deshalb baute das Team einen eigenen mit reflex-spezifischen Regeln.
Beim Profiling fiel auf, dass nicht die isinstance-Prüfungen die Zeit fraßen, sondern ast.walk. Diese Funktion läuft durch jeden Knoten des abstrakten Syntaxbaums und prüft dabei auch Felder, die für die eigentliche Aufgabe gar nicht gebraucht werden. Bei viel Code summiert sich das.
Wie kommt eine 220-fache Beschleunigung zustande?
Der Trick liegt in der Struktur der Knoten. Die internen Felder eines AST-Knotens sind vorhersehbar geordnet: zuerst die eigentlichen Inhalte, danach Metadaten wie Zeilennummer und Spaltenversatz. Wer nur die vorab bekannte Zahl der Inhaltsfelder durchläuft, spart sich die Prüfung der Metadaten komplett.
Dazu kommt ein zweiter Effekt: Der Ansatz ignoriert von Nutzern angehängte Rückverweise auf Elternknoten, die manche Lint-Regeln setzen. Beide Optimierungen zusammen ergeben rund 99,5 Prozent Ersparnis. Das quelloffene Projekt fast-walk geht mit gebündeltem Prefetching noch einen Schritt weiter und holt etwas mehr heraus.
Der teuerste Code ist oft der, den niemand hinterfragt, weil er aus der Standardbibliothek kommt. Hier lag der Engpass nicht im eigenen Werk, sondern in einer Funktion, die alle benutzen. Profiling vor Bauchgefühl, das ist die Lehre.
— Michael Dobler, Herausgeber Dr. Web
Was nehmen Entwickler aus dem Fall mit?
Die Episode ist ein Lehrstück über Profiling. Wer Performance-Probleme vermutet, sollte messen statt raten, denn der Flaschenhals saß an einer Stelle, die kaum jemand verdächtigt. Gerade bei massenhaft generiertem Code, wie ihn KI-Werkzeuge produzieren, zahlt sich die genaue Analyse aus.
Der Fall passt zu einer breiteren Frage, die das Jahr 2026 prägt: Wie gut ist maschinell erzeugter Code wirklich? Ein neuer Benchmark misst genau das und kommt zu einem ernüchternden Ergebnis, nachzulesen in unserer Einordnung dazu, ob KI wirklich guten Code schreibt. Für die eigene Toolchain lohnt der Blick in unseren Vergleich von HTML-Editoren und KI-Tools.
Mehr Newshunger?
