💬 NLP

Evaluating LLMs on Real-World Software Performance Optimization

Dieses Paper führt SWE-Pro ein, einen rigorosen Repository-Level-Benchmark, der aus 102 Experten-Optimierungen abgeleitet wurde und aufzeigt, dass aktuelle Large Language Models signifikant daran scheitern, die menschliche Leistungsfähigkeit bei realen Software-Optimierungen zu erreichen, indem sie im Vergleich zu den erheblichen Geschwindigkeitssteigerungen und Speicherreduzierungen, die von Experten-Ingenieuren geliefert werden, vernachlässigbare Gewinne erzielen.

Ursprüngliche Autoren: Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

Veröffentlicht 2026-06-25

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Ganze: Der „Schnelle Koch“ vs. der „Meisterkoch“

Stellen Sie sich vor, Sie haben eine riesige, geschäftige Restaurantküche (eine reale Software-Codebasis). Sie stellen ein Team von KI-Köchen (Large Language Models oder LLMs) ein, um den Meisterköchen (menschlichen Experten) zu helfen, schneller zu kochen und weniger Energie zu verbrauchen.

Die Meisterköche wissen genau, wie man Gemüse effizient hackt, die Vorratskammer organisiert, um Wege zu sparen, und die Herdtemperatur anpasst, um Brennstoff zu sparen. Sie verfügen über jahrelange Erfahrung.

Die KI-Köche sind unglaublich intelligent. Sie können das Rezept lesen, die Zutaten verstehen und sogar neue Rezepte schreiben, die auf dem Papier perfekt aussehen. Aber die große Frage, die diese Arbeit stellt, ist: Können diese KI-Köche die Küche in der realen Welt tatsächlich schneller machen und weniger Energie verbrauchen, oder lassen sie Dinge nur gut aussehen, ohne die Geschwindigkeit tatsächlich zu verbessern?

Das Problem: Die alten Tests waren zu einfach

Früher testeten Forscher KI-Köche, indem sie ihnen eine einzige, winzige Aufgabe gaben: „Hacke diese eine Karotte.“

Der Fehler: In einer echten Küche hacken Sie nicht nur eine Karotte. Sie hacken 10, 1.000 oder 100.000. Manchmal sind die Karotten nass; manchmal sind sie gefroren.
Das Ergebnis: Die alten Tests waren so, als würde man einen Koch danach bewerten, wie gut er eine einzelne Karotte in einem ruhigen Raum hackt. Sie testeten nicht, ob der Koch eine Stoßzeit mit 1.000 Bestellungen bewältigen konnte, oder ob der Koch versehentlich zu viel Wasser (Speicher) verbrauchte, während er versuchte, schnell zu sein.

Die Arbeit argumentiert, dass diese alten Tests zu einfach waren und das „Rauschen“ (zufällige Schwankungen), das in echten Computern auftritt, nicht erfassten.

Die Lösung: SWE-Pro (Der „Reale-Küche“-Simulator)

Die Autoren haben einen neuen, viel schwierigeren Test namens SWE-Pro entwickelt. Betrachten Sie dies als eine hochtechnologische Simulation einer chaotischen, realen Küche.

Reale Rezepte: Sie haben keine erfundenen Aufgaben erstellt. Sie haben sich 102 reale Beispiele angesehen, bei denen menschliche Experten erfolgreich Code in berühmten Open-Source-Projekten (wie pandas, scikit-learn und xarray) optimiert haben. Dies sind die „Goldstandard“-Rezepte.
Der Stresstest: Anstatt die KI nur an einem Input zu testen, testet SWE-Pro sie auf vielen verschiedenen Szenarien.
- Analogie: Es heißt nicht nur „hacke 10 Karotten“. Es heißt: „hacke 10 Karotten“, dann „hacke 100“, dann „hacke 10.000“ und mache das mit nassen Karotten, gefrorenen Karotten und Karotten unterschiedlicher Größe.
Der Rauschfilter: Computer sind unordentlich. Manchmal läuft ein Programm langsam, nur weil der Computer gerade mit etwas anderem beschäftigt war (wie ein Kellner, der ein Tablett fallen lässt). SWE-Pro führt die Tests immer wieder aus und verwendet einen speziellen statistischen „Rauschfilter“, um sicherzustellen, dass, wenn eine KI sagt „Ich bin schneller“, dies auch wirklich wahr ist und kein bloßer Glückstreffer.
Zwei Metriken: Sie messen zwei Dinge:
- Geschwindigkeit: Wie schnell das Essen serviert wird (Laufzeit).
- Speicher: Wie viel Platz auf der Arbeitsplatte und wie viel Lagerplatz der Koch benötigt (Peak Memory und Time-Weighted Memory Usage).

Die Ergebnisse: Die KI-Köche kämpfen

Als sie die besten KI-Modelle (wie GPT-5.2, Claude Sonnet 4.6 usw.) durch diesen strengen „Real-Kitchen“-Test schickten, waren die Ergebnisse überraschend und enttäuschend.

Die menschlichen Experten (Goldstandard): Wenn Menschen den Code optimierten, erzielten sie massive Verbesserungen.
- Analogie: Der Meisterkoch verkürzte die Kochzeit um das 15-fache und reduzierte den benötigten Platz auf der Arbeitsplatte um das 171-fache. Er fand clevere Wege, die Küche neu zu organisieren, was enorme Ressourcen einsparte.
Die KI-Köche:
- Geschwindigkeit: Die KI-Modelle machten kaum einen Unterschied. In den meisten Fällen waren ihre „Verbesserungen“ so gering, dass sie nicht vom zufälligen Rauschen unterschieden werden konnten.
- Speicher: Die KI-Modelle haben fast nie geschafft, Speicher zu sparen. In diesem Bereich waren sie nahezu nicht existent.
- Das „Kein-Signal“-Problem: Selbst wenn die KI Code schrieb, der die grundlegenden Tests bestand (das Essen schmeckte richtig), produzierte sie selten eine messbare Beschleunigung. Es war wie ein Koch, der die Karotten ordentlich gehackt hat, aber exakt die gleiche Zeit wie zuvor benötigt hat.
- Die Regression: Manchmal machte die KI die Dinge sogar langsamer. Ein Modell (GPT-5.2) machte den Code im Durchschnitt sogar 30 % langsamer!

Die wichtigste Erkenntnis

Die Arbeit kommt zu dem Schluss, dass KI zwar großartig darin ist, Code zu schreiben, der korrekt aussieht und den Regeln folgt, aber derzeit sehr schlecht in dem tiefen, komplexen Engineering ist, das erforderlich ist, um Software in realen Szenarien signifikant schneller laufen zu lassen oder weniger Speicher zu verbrauchen.

Die Lücke: Es gibt eine riesige Kluft zwischen dem, was KI heute leisten kann, und dem, was erfahrene menschliche Ingenieure leisten können.
Der Flaschenhals: Das Problem ist nicht, dass die KI keine großen Verbesserungen erzielen kann, wenn sie Glück hat (das kann sie in seltenen Fällen). Das Problem ist, dass die KI nicht zuverlässig die Gelegenheiten findet, um diese Verbesserungen überhaupt erst zu realisieren.

Kurz gesagt: Wenn Sie eine KI bitten, „diese Software schneller zu machen“, schreibt sie vielleicht einen hübsch aussehenden Patch, aber erwarten Sie nicht, dass sie tatsächlich Ihren Computer beschleunigt oder Speicher spart. Für den Moment gehört dieser Job immer noch den menschlichen Experten.

Technisches Resümee: SWE-Pro – Evaluierung von LLMs hinsichtlich der Performance-Optimierung in realen Softwareumgebungen

1. Problemstellung

Die Performance-Optimierung von Software ist eine komplexe, manuelle Ingenieursaufgabe, die durch multidimensionale Trade-offs (z. B. Laufzeit vs. Speicher) und eine hohe Sensitivität gegenüber Ausführungsumgebungen und Eingabedaten gekennzeichnet ist. Während Large Language Models (LLMs) bereits Kompetenz in der Codegenerierung und Fehlerbehebung gezeigt haben, bleibt ihre Fähigkeit zur repositoriumsweiten Performance-Optimierung unterbewertet.

Bestehende Benchmarks leiden unter kritischen Einschränkungen:

Vereinfachung: Viele konzentrieren sich auf isolierte Funktionen (z. B. EffiBench) oder einzelne, feste Workloads, wodurch die Komplexität realer Repositorien nicht erfasst wird.
Defizite bei den Metriken: Aktuelle Frameworks evaluieren oft nur die Laufzeit und vernachlässigen dabei den Speicherverbrauch sowie die entscheidenden Zeit-Speicher-Trade-offs, die für Optimierungen inhärent sind.
Messrauschen: Benchmarks verlassen sich häufig auf eine feste Anzahl von Profiling-Durchläufen oder grobkörnige Aggregationen, was die eingabespezifischen Performance-Fluktuationen verschleiert und es versäumt, echte Gewinne von Umgebungslärm (z. B. Scheduler-Jitter, Cache-Effekte) zu unterscheiden.
Mangel an statistischer Rigorosität: Es gibt einen Mangel an Benchmarks, die adaptive Messungen und statistische Konvergenz einsetzen, um sicherzustellen, dass beobachtete Verbesserungen reproduzierbar und signifikant sind.

Folglich bleibt unklar, ob aktuelle LLMs in der Lage sind, die Komplexität realer Software-Performance zu navigieren, um robuste, Experten-Level-Optimierungen zu liefern.

2. Methodik: Der SWE-Pro Benchmark

Um diese Lücken zu schließen, führen die Autoren SWE-Pro ein, einen repositoriumsweiten Benchmark, der aus 102 von Experten geschriebenen Optimierungen aus drei großen Open-Source-Python-Datenbibliotheken abgeleitet wurde: pandas, scikit-learn und xarray.

2.1 Datensatz-Konstruktion

Quelle: Zusammengeführte Pull Requests (PRs), die explizit als performance-bezogen gekennzeichnet sind und eine Bestätigung der Entwickler in den Changelogs oder der Dokumentation aufweisen.
Validierung: Manuelle Inspektion stellt sicher, dass die Aufgaben reproduzierbar sind, Python-Quellcode-Modifikationen beinhalten und echte Optimierungsmöglichkeiten darstellen.
Goldstandard: Jede Aufgabe umfasst den ursprünglichen Codebase, den von Experten verfassten Patch (Gold Solution) und einen Satz parametrisierter Performance-Tests.

2.2 Parametrisierte Performance-Tests

Im Gegensatz zu Benchmarks, die feste Eingaben verwenden, nutzt SWE-Pro strukturierte Parameter-Sweeps, um die Performance über diverse Workloads hinweg zu evaluieren.

Dimensionen: Tests variieren Eingabegröße, Datenverteilung (Sparsity, Duplikation), Datentyp und funktionsspezifische Konfigurationen.
Workload-Generierung: Parameter werden mittels kartesischer Produkte kombert, um Ausführungskonfigurationen zu generieren (Median 6 pro Aufgabe, bis zu 24), wodurch sichergestellt wird, dass die Evaluierung erfasst, wie Optimierungen unter verschiedenen Bedingungen generalisieren oder degradieren.

2.3 Zuverlässiges Mess-Framework

SWE-Pro implementiert eine hierarchische, rauschbewusste Messpipeline, um statistische Signifikanz zu gewährleisten:

Adaptive Iterationen: Anstatt fester Durchlaufzahlen bestimmt das System dynamisch die Anzahl der Messiterationen basierend auf der Konvergenz der 90% relativen Konfidenzintervallbreite (RCIW).
Hierarchische Rauschmodellierung: Das Framework berücksichtigt sowohl Innerhalb-des-Containers-Rauschen (Scheduler-Jitter, Interpreter-Verhalten) als auch Across-Container-Rauschen (CPU-Zustand, Speicherlayout), indem die Workloads in frischen Docker-Instanzen ausgeführt werden.
Signal-Rausch-Verhältnis (SNR): Nur Performance-Effekte, die einen rauschbewussten Schwellenwert überschreiten (SNR ≥ 2), werden als valide Verbesserungen akzeptiert.
Multi-Metrik-Evaluierung: Der Benchmark verfolgt drei distinkte Metriken:
- Laufzeit: Ausführungszeit.
- Peak Memory: Maximaler Speicherverbrauch über dem Baseline-Niveau.
- Zeitgewichteter Speicherverbrauch (TWMU): Eine normalisierte Metrik, die den Speicherdruck über die Zeit integriert, berechnet als $\bar{m}_{twmu} = \frac{1}{T} \int_0^T \max(0, m(t) - m_{base}) dt$ .

2.4 Experimentelles Setup

Modelle: Sechs State-of-the-Art LLMs wurden evaluiert (GPT-5.2, Claude Sonnet 4.6, Kimi K2.5, Gemini 3.1 Flash-Lite, GLM-5.1, MiniMax M2.7).
Kontext-Strategien: Die Modelle wurden unter zwei Retrieval-Bedingungen getestet:
- Oracle: Die relevanten Dateien der Grundwahrheit (Ground-Truth) werden direkt bereitgestellt.
- BM25: Kontext, der via lexikalischer Ähnlichkeit aus dem Repositoriumsstatus abgerufen wurde.
Evaluierungsmetriken: Patch-Erfolgsrate (Anwendbarkeit), funktionale Korrektheit (Test-Pass-Rate) und der Performance-Verbesserungsfaktor (IF), berechnet via harmonischem Mittel über die Workloads.

3. Kernergebnisse

Die Evaluierung offenbart eine erhebliche Lücke zwischen aktuellen LLM-Fähigkeiten und Experten-Engineering.

3.1 Patch-Generierung und Korrektheit

Anwendbarkeit: Unter Oracle-Retrieval lagen die Patch-Anwendungsraten zwischen 30,4 % und 97,1 %.
Korrektheit: Selbst wenn Patches erfolgreich angewendet wurden, waren die Raten der funktionalen Korrektheit mit 18,6 % bis 79,4 % signifikant niedriger, was darauf hindeutet, dass LLMs häufig syntaktisch korrekten, aber semantisch inkorrekten Code produzieren.
Retrieval-Impact: Die Performance sank unter BM25-Retrieval weiter, was die Sensitivität von Optimierungsaufgaben gegenüber der Kontextqualität unterstreicht.

3.2 Fähigkeiten zur Performance-Optimierung

Laufzeit: LLMs haben Schwierigkeiten, messbare Laufzeitgewinne zu erzielen.
- Nur ein kleiner Bruchteil der Aufgaben bestand den SNR-Filter (z. B. erreichte Gemini 3.1 Flash eine Pass-Rate von 12,7 % unter Oracle).
- Das Ausmaß der Verbesserung war im Vergleich zum Gold-Solution-Speedup von 15,48× vernachlässigbar (z. B. IF von 1,27× beim besten Modell).
- Einige Modelle (z. B. GPT-5.2) produzierten Patches, welche die Performance verschlechterten (IF < 1).
Speicheroptimierung: LLMs zeigten nahezu nicht vorhandene Fähigkeiten in der Speicheroptimierung.
- Verbesserungen beim Peak Memory und TWMU waren über alle Modelle hinweg weitgehend abwesend.
- Die einzige nennenswerte Ausnahme war Claude Sonnet 4.6 in einer einzelnen Instanz (PR #7578), die hohe IFs erzielte (16,61× Peak Memory, 28,82× TWMU unter Oracle; 3556× TWMU unter BM25). Diese Gewinne generalisierten jedoch nicht über die Aufgaben hinweg.
- Im Gegensatz dazu erreichten die Gold Solutions eine Reduktion des Peak Memory um 171,31× und eine Reduktion des TWMU um 619,22× in 55,9 %–70,6 % der Aufgaben.

3.3 Workload-Sensitivität

Die Studie hebt hervor, dass die Effektivität der Optimierung stark von den Eingabedaten abhängt. Beispielsweise skalierten die Laufzeitverbesserungen in PR #7578 signifikant mit der Eingabegröße (bis zu 100× für große Workloads), während die Speicherverbesserungen stabil blieben. Dies unterstreicht die Notwendigkeit parametrisierter Tests, da Single-Input-Benchmarks diese kritischen Verhaltensweisen übersehen würden.

4. Bedeutung und Beiträge

Das Paper beansprucht die folgenden Beiträge:

SWE-Pro Benchmark: Ein umfassender, repositoriumsweiter Benchmark bestehend aus 102 Experten-validierten Aufgaben mit parametrisierten Tests, der darauf abzielt, die Evaluierung hin zu einer robusten, workload-bewussten Analyse zu verschieben.
Rauschbewusstes Framework: Eine neuartige Messpipeline, die adaptive Stichproben, hierarchische Rauschmodellierung und SNR-Filterung nutzt, um echte Optimierung von Umgebungsvarianz zu unterscheiden.
Multi-Metrik-Einblick: Die erste systematische Studie, die Runtime, Peak Memory und TWMU gemeinsam evaluiert und aufzeigt, dass aktuelle LLMs nicht in der Lage sind, Zeit-Speicher-Trade-offs effektiv zu navigieren.
Empirischer Beleg für Limitationen: Die Ergebnisse legen eine „erhebliche Lücke“ offen, in der aktuelle LLMs trotz exzellenter lokaler Logik-Verfeinerungen scheitern, messbare Effizienzgewinne in realen Szenarien zu liefern. Der primäre Engpass wird nicht in der Größenordnung der potenziellen Verbesserungen identifiziert, sondern in der zuverlässigen Identifizierung der Optimierungsmöglichkeiten selbst.

Die Autoren kommen zu dem Schluss, dass LLMs zwar in spezifischen, isolierten Fällen vielversprechend sind, aber derzeit die systematische Argumentation vermissen lassen, die für Experten-Level-Performance-Engineering erforderlich ist, was die Forschung in Richtung Modellen notwendig macht, die in der Lage sind, komplexe, Multi-Metrik-Optimierungslandschaften zu navigieren. Der SWE-Pro Datensatz und die Evaluierungs-Pipeline werden zur Unterstützung weiterer Forschungsarbeiten der Community Open-Source zur Verfügung gestellt.