Do AI Models Dream of Faster Code? An Empirical Study on LLM-Proposed Performance Improvements in Real-World Software

Probleemstelling

Hoewel Large Language Models (LLM's) steeds beter worden in het genereren van functioneel correcte code, blijft hun vermogen om prestatie-optimalisaties aan te brengen in complexe, real-world softwaresystemen onzeker. Bestaande evaluaties zijn vaak gebaseerd op geïsoleerde algoritmische puzzels (zoals LeetCode of HumanEval), die de complexiteit van productiecode niet weerspiegelen. In echte systemen hangen prestaties af van factoren zoals concurrency, geheugenallocatie en cross-file afhankelijkheden. Er is een gebrek aan empirisch bewijs over of LLM's daadwerkelijk kunnen fungeren als effectieve "Performance Engineers" in industriële settings, en of huidige benchmarks de capaciteiten van LLM's niet te optimistisch beoordelen.

Methodologie

De auteurs hebben een empirische studie uitgevoerd met de volgende stappen:

1. Dataset Constructie (PerfOpt):

   • Er is een dataset samengesteld van 65 real-world prestatie-taken afkomstig uit vier grote open-source Java-projecten: Apache Kafka, Netty, Presto en RoaringBitmap.
   • In tegenstelling tot synthetische benchmarks, zijn deze taken afgeleid van daadwerkelijke commits waar ontwikkelaars prestatieverbeteringen hebben aangebracht, vergezeld van JMH (Java Microbenchmark Harness) benchmarks om de verbetering kwantitatief te verifiëren.
   • Alleen taken met statistisch significante verbeteringen (gevalideerd via de Wilcoxon signed-rank test en Vargha-Delaney effect size) werden geselecteerd.

2. Experimenteel Opzet:

   • Modellen: Er zijn vier LLM's getest: OpenAI o4-mini, Gemini 2.5 Pro, DeepSeek-V3 en DeepSeek-R1 (een redenerend model).
   • Prompt-strategieën: Vier verschillende context-niveaus werden getest:
     • No Hint: Alleen code en een algemene vraag.
     • Met Benchmark: Code + JMH-benchmarkcode.
     • Met Probleembeschrijving: Code + natuurlijke taalbeschrijving van het probleem.
     • Both: Code + benchmark + probleemomschrijving.
   • Validatie: Een geautomatiseerde "repair loop" werd gebruikt om onbruikbare patches (compilatiefouten of falende tests) te herstellen.
   • Evaluatie: De gegenereerde patches werden uitgevoerd in een gecontroleerde VM-omgeving met JMH. De prestaties werden gemeten als een ratio (Patch Performance Score - PPS) ten opzichte van de originele code.

3. Analyse:

   • Statistische vergelijkingen (Wilcoxon signed-rank test) tussen LLM-oplossingen, menselijke oplossingen en de basislijn.
   • Manuele labeling van patches om te bepalen of de strategie van de LLM overeenkwam met die van de menselijke ontwikkelaar (Match, Alignment, of Divergence).
   • Analyse van code-complexiteit (LOC, Cyclomatic Complexity).

Belangrijkste Bijdragen

• PerfOpt Dataset: De introductie van een nieuwe, realistische benchmark voor prestatie-optimalisatie in productie-omgevingen, in plaats van geïsoleerde algoritmen.
• Empirisch Bewijs: Het leveren van robuust bewijs dat huidige LLM's moeite hebben met autonome prestatie-optimalisatie in complexe systemen, ondanks hun sterke generatieve capaciteiten.
• Kritische Analyse van Bestaande Benchmarks: Het aantonen dat benchmarks gebaseerd op algoritmische taken de prestaties van LLM's te optimistisch inschatten voor real-world scenario's.

Resultaten

1. Prestatieverbetering (RQ1):

• Mens vs. AI: Menselijke ontwikkelaars presteren over het algemeen significant beter dan LLM's. Hoewel LLM's vaak prestatieverbeteringen kunnen genereren (in vergelijking met de originele code), halen ze zelden het niveau van de menselijke oplossing.
• Vluchtigheid: De resultaten van LLM's zijn extreem volatiel. In sommige gevallen vinden ze innovatieve oplossingen die menselijke ontwikkelaars missen (bijv. in Kafka), maar in andere gevallen veroorzaken ze ernstige regressies (vertragingen), vooral in complexe projecten zoals Presto.
• Invloed van Context: Het verstrekken van een duidelijke probleembeschrijving is cruciaal. Zonder context ("No Hint") presteren modellen slecht. De combinatie van probleemomschrijving en benchmarkcode ("Both") levert de beste resultaten op, maar zelfs dan blijven ze vaak achter bij menselijke experts.
• Modellen: Commerciële modellen (Gemini 2.5 Pro) presteerden over het algemeen iets beter dan open-weight modellen, maar geen enkel model was consistent superieur.

2. Strategie en Complexiteit (RQ2):

• Structuur: LLM-patches zijn vaak meer lokaal (minder bestanden aangepast) maar introduceren hogere cyclomatische complexiteit. Mensen neigen naar structurele vereenvoudiging, terwijl LLM's neigen naar complexe logica om prestaties te verbeteren.
• Strategie Overeenkomst:
  • Strategy Match: De LLM gebruikt exact dezelfde logica als de mens (zelden, ~13-32%).
  • Strategy Alignment: De LLM herkent het probleem maar gebruikt een andere, vaak suboptimale aanpak (~45-59%).
  • Strategy Divergence: De LLM lost een ander, irrelevant probleem op of mist de bottleneck volledig (~5-35%, afhankelijk van de prompt).
• Conclusie: Zonder expliciete gids (probleembeschrijving) divergeren modellen vaak. Zelfs met gids vinden ze zelden de optimale menselijke oplossing, maar eerder een werkende maar minder efficiënte variant.

Betekenis en Conclusie

De studie concludeert dat LLM's momenteel fungeren als hoog-variatie zoekmachines in plaats van betrouwbare engineers voor prestatie-optimalisatie.

• Beperkingen: LLM's missen het vermogen om autonoom "hotspots" te profileren en runtime-gedrag te analyseren. Ze kunnen de context van een systeem niet volledig doorgronden zonder expliciete aanwijzingen.
• Toekomstige Richting:
  • Agent-based Systemen: De toekomst ligt niet in statische code-generatie, maar in agenten-systemen die tools voor profiling, tracing en runtime-benchmarking integreren.
  • Rol van de Mens: De meest effectieve workflow is een samenwerking waarbij de mens de diagnose en benchmark levert, en de LLM de implementatie genereert.
  • Benchmarks: De gemeenschap moet overstappen van synthetische algoritmische benchmarks naar realistische datasets zoals PerfOpt om de echte capaciteiten van AI in software-engineering te meten.

Kortom, AI-modellen dromen misschien van snellere code, maar zonder menselijke begeleiding en runtime-inzichten zijn hun dromen vaak onbetrouwbaar en soms zelfs schadelijk voor de prestaties van productie-systemen.