💻 computer science

JETO-Bench: A Reproducible Benchmark for Execution Time Improvement Patches in Java

Dit artikel introduceert JETO-Mine, een nieuwe configureerbare tool voor het genereren van reproduceerbare benchmarks van patches voor verbetering van de uitvoeringstijd in Java, die werd gebruikt om JETO-Bench te creëren—een dataset van 660 geïdentificeerde patches uit 174 repositories—en toonde aan dat huidige coding agents zoals OpenHands een succespercentage van 14,3% behalen op deze taken, terwijl het een aanzienlijk gebrek aan prestatiegerelateerde tests in open-source projecten benadrukt.

Oorspronkelijke auteurs: Khashayar Etemadi, Zhendong Su

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC0 1.0

Oorspronkelijke auteurs: Khashayar Etemadi, Zhendong Su

Oorspronkelijk artikel vrijgegeven aan het publieke domein onder CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme bibliotheek hebt met softwarecode geschreven in Java, een populaire programmeertaal. Jarenlang hebben onderzoekers geprobeerd om "robotmechanici" (AI-agenten) te bouwen die automatisch bugs in deze code kunnen vinden en oplossen. Echter, de meeste van deze robots zijn alleen getraind om functionele bugs op te lossen — fouten waarbij de software crasht of het verkeerde antwoord geeft (zoals een rekenmachine die 2+2=5 zegt).

Wat betreft prestatiebugs? Dit zijn fouten waarbij de software correct werkt, maar ongelooflijk traag is, zoals een automotor die prima functioneert maar sputtert en er eeuwig over doet om 60 mph te bereiken. Tot nu toe was het erg moeilijk om te testen of onze robotmechanici deze "trage" problemen konden oplossen, vooral in Java.

Hier is een eenvoudige uitsplitsing van wat dit artikel introduceert:

1. Het Probleem: De "Volatiliteit" van Java

Het oplossen van snelheidsproblemen in Java is als het timen van een hardloper op een atletiekbaan die elke paar seconden van ondergrond verandert.

De Uitdaging: Java heeft een speciale "motor" (de JVM) die sneller wordt naarmate je hem meer gebruikt (Just-In-Time compilatie) en af en toe stopt om zijn werkplek op te ruimen (Garbage Collection). Dit maakt het meten van snelheid erg lastig. Een test kan traag lijken simpelweg omdat de computer aan het "opwarmen" was, niet omdat de code slecht is.
De Kloof: Bestaande benchmarks (testsets) voor het oplossen van snelheidsproblemen bestaan voornamelijk voor andere talen zoals Python of C++. Java mist een eerlijke, betrouwbare testset.

2. De Oplossing: JETO-Mine (De "Goudzoeker")

De auteurs hebben een tool gebouwd genaamd JETO-Mine. Zie dit als een hoogtechnologische goudzoekmachine voor softwarecode.

Fase 1: De Zoektocht (Statische Analyse): De machine scant miljoenen commits (wijzigingen) op GitHub. Het gebruikt een slimme AI (een LLM) om de "notities" te lezen die ontwikkelaars achterlieten bij wijzigingen, op zoek naar aanwijzingen die zeggen: "Ik heb dit sneller gemaakt."
Fase 2: Het Laboratorium (Dynamische Analyse): Dit is het belangrijkste deel. Zodra een potentiële "snelheidsfix" is gevonden, plaatst JETO-Mine de code in een Docker-container. Zie dit als een verzegeld, identiek laboratorium voor elke enkele test.
- Het voert de code 30 keer uit om een gemiddelde te krijgen.
- Het gebruikt strikte wiskunde (statistische toetsing) om te bewijzen dat de versnelling echt is en geen toevalstreffer door de willekeurige ruis van de computer.
- Het zorgt ervoor dat de "voor"- en "na"-versies in exact dezelfde omgeving draaien, zodat de vergelijking eerlijk is.
Fase 3: De Rechter (Evaluatie Harness): Dit is een scheidsrechter die controleert of een fix van een robotmechanicus daadwerkelijk werkt. Het voert de nieuwe code uit, controleert of deze nog steeds alle oorspronkelijke tests doorstaat, en meet of deze echt sneller is.

3. Het Resultaat: JETO-Bench (De "Schatkist")

Met behulp van JETO-Mine hebben de onderzoekers JETO-Bench gecreëerd.

Ze hebben 11 jaar aan geschiedenis en bijna 1,8 miljoen code-wijzigingen doorzocht.
Ze vonden 660 potentiële snelheidsfixes.
Na rigoureuze tests hebben ze 91 hiervan geverifieerd als "gouden standaard" fixes die gegarandeerd werken en reproduceerbaar zijn.
Belangrijke Ontdekking: Ze ontdekten dat de meeste open-source Java-projecten geen tests hebben die bewijzen dat een stuk code sneller is. Het is alsof je een racewagen hebt, maar geen stopwatch om te bewijzen dat hij snel is. Dit is een enorme kloof in hoe software momenteel wordt getest.

4. De Proefrit: Kan AI deze bugs oplossen?

Om te zien of JETO-Bench nuttig is, hebben de onderzoekers een leidende AI-coderingsagent genaamd OpenHands gevraagd om deze 91 snelheidsproblemen op te lossen.

De Score: OpenHands loste 14,3% van de problemen succesvol op.
De Betekenis: Dit resultaat is vergelijkbaar met wat andere studies vonden voor Python en C++. Het laat zien dat hoewel AI beter wordt, het oplossen van "trage" code nog steeds erg moeilijk is.
De Bonus: De "Rechter" (evaluatie harness) heeft bijna alle foutieve fixes automatisch betrapt. Als de AI probeerde het verkeerde deel van de code te repareren of de build verbrak, wist het systeem dit onmiddellijk.

5. Waarom dit ertoe doet

Reproduceerbaarheid: Vóór dit moment moest je, als je een nieuwe tool voor het oplossen van snelheid wilde testen, hopen dat de originele code jaren later nog steeds werkte. JETO-Bench biedt een verzegelde, tijdscapsule-omgeving (Docker), zodat iedereen vandaag exact dezelfde test kan draaien en hetzelfde resultaat krijgt.
Een Nieuwe Uitdaging: Het artikel benadrukt dat we nieuwe manieren moeten uitvinden om tests te schrijven die snelheid meten, en niet alleen juistheid.
Nog Geen Wonderwapen: De studie bevestigt dat zelfs geavanceerde AI-agenten worstelen met prestatie-optimalisatie, wat suggereert dat dit een nieuw gebied is dat meer onderzoek vereist.

In een notendop: De auteurs hebben een machine gebouwd (JETO-Mine) om echte, werkende voorbeelden te vinden van Java-code die sneller wordt. Ze hebben deze voorbeelden verpakt in een testset (JETO-Bench) en bewezen dat huidige AI-robots ongeveer 1 op de 7 van deze snelheidsproblemen kunnen oplossen, maar ze hebben ook onthuld dat de softwarewereld de instrumenten (tests) mist om snelheidswinsten überhaupt goed te meten.

Technische Samenvatting: JETO-Bench en JETO-Mine

Probleemstelling

Automated Program Repair (APR) heeft aanzienlijke vooruitgang geboekt, gedreven door benchmarks zoals Defects4J en SWE-Bench. Deze benchmarks richten zich echter voornamelijk op functionele bugs, waardoor niet-functionele kwesties, specifiek uitvoeringstijdprestaties, ondervertegenwoordigd blijven. Hoewel er benchmarks bestaan voor patches die de uitvoeringstijd verbeteren (ETIPs) voor Python, C++ en .NET (bijv. PIE, SWE-Perf, PerfBench), blijft Java grotendeels afwezig.

De afwezigheid van Java-benchmarks is kritiek vanwege de specifieke runtime-kenmerken van de taal. De afhankelijkheid van Java van Just-In-Time (JIT) compilatie en Garbage Collection (GC) introduceert volatiliteit in metingen van de uitvoeringstijd. In tegen tegenstelling tot Python of C++, waar de uitvoeringstijd directer gekoppeld is aan de broncode, vereisen Java-metingen een rigoureuze behandeling van JVM warm-up, GC-interferentie en niet-deterministische pauzes. Bovendien zijn bestaande Java-datasets (bijv. Yi et al.) vast, niet uitbreidbaar en missen ze gecontaineriseerde omgevingen, wat reproduceerbaarheid bemoeilijkt naarmate projectafhankelijkheden evolueren. Ten slotte kunnen huidige prestatiebenchmarks over het algemeen niet worden uitgebreid om nieuwe real-world patches te verzamelen op basis van gebruikersgedefinieerde configuraties.

Methodologie: JETO-Mine

Om deze hiaten aan te pakken, presenteren de auteurs JETO-Mine, een configureerbare en herbruikbare tool die ontworpen is om reproduceerbare benchmarks van ETIPs in real-world Java-projecten automatisch te creëren. JETO-Mine werkt via een driefasige pijplijn:

1. Statische Analyse Fase

Deze fase doorzoekt GitHub-repositories om potentiële ETIPs te identificeren met behulp van gebruikersgedefinieerde filters en een LLM-gebaseerde classifier.

Repository Selectie: Filtert op actieve Java-projecten (Java 8+, Maven Wrapper) met specifieke sterren-aantallen en recente update-data.
Commit/PR Filtering: Analyseert diffs op de default branch, waarbij wijzigingen die alleen .java bestanden beïnvloeden, testbestanden uitsluiten en een beperkt aantal bestanden wijzigen, worden behouden.
LLM Classificatie: Prompt een LLM met de issue-titel, beschrijving en commit-bericht om te bepalen of de wijziging primair gericht is op het verbeteren van de uitvoeringstijd.
Deduplicatie: Vervangt individuele commits door hun bijbehorende Pull Requests (PRs) om de volledige ontwikkelaarsintentie te vangen en de-dupliceert op basis van code-diffs.

2. Dynamische Analyse Fase

Deze fase transformeert geïdentificeerde ETIPs naar uitvoerbare, reproduceerbare omgevingen met behulp van Docker.

Omgeving Constructie: Maakt Docker-images aan die de specifieke Java-versie en afhankelijkheden bevatten die nodig zijn om het project te bouen en te testen.
JVM Mitigatie: Om de JVM-volatiliteit tegen te gaan, voert de pijplijn een toegewezen "warm-up" ronde uit (die wordt weggegooid) vóór de getimede executies. Het voert testsuites meerdere keren uit (standaard $n=30$ ) binnen identieke JVM-configuraties om variatie in GC en JIT te minimaliseren.
Statistische Testen: Voert gepaarde eenzijdige binomiale tests uit op de uitvoeringstijden tussen de originele en de gepatchte versies. Een patch wordt beschouwd als een ETIP als deze een statistisch significante verbetering laat zien (configureerbare $p$ -waarde en minimaal verbeteringspercentage) in specifieke testklassen.
Validatie: Garandeert dat het project bouwt en alle tests slaagt voor beide versies. Als een patch niet kan bouwen of bestaande tests breekt, wordt deze uitgesloten.

3. Evaluatie Harness

Deze fase biedt tools voor kwantitatieve beoordeling van gegenereerde patches en tests.

Patch Evaluatie: Neemt een gegenereerde patch, past deze toe op de originele code binnen de Docker-container, en voert statistische tests uit om te bepalen of de patch de uitvoeringstijd verbetert.
Test Generatie Evaluatie: Ondersteunt de evaluatie van tools die "ETIP detector tests" genereren (tests die prestatieverbeteringen statistisch kunnen verifiëren).

Belangrijkste Bijdragen

1. JETO-Mine Tool

De eerste configureerbare tool voor het creëren van reproduceerbare Java ETIP-benchmarks. Het stelt onderzoekers in staat om continu nieuwe benchmarks te verzamelen met aangepaste filters en statistische strengheidsniveaus, wat de rigiditeit van bestaande datasets aanpakt.

2. JETO-Bench Benchmark

Met behulp van JETO-Mine hebben de auteurs JETO-Bench geconstrueerd, bestaande uit:

660 Geïdentificeerde ETIPs: Verzameld uit 174 open-source Java-repositories verspreid over 11 jaar aan ontwikkelingsgeschiedenis (bijna 1,8 miljoen commits).
91 Handmatig Geverifieerde Uitvoerbare ETIPs: Een gecureerde subset waarbij de patches succesvol bouwen, tests passeren en gekoppeld zijn aan beschrijvende issues. Deze worden vergezeld door Docker-images voor volledige reproduceerbaarheid.
Diversiteit: De benchmark dekt diverse projecttypen (gedistribueerde systemen, cloud-native frameworks) en bevat multi-file en multi-module patches, geschikt voor het evalueren van repository-level repair tools.

3. Empirische Evaluatie

De auteurs evalueerden OpenHands, een leidende open-source coding agent, op de 91 geverifieerde ETIPs.

Succespercentage: OpenHands heeft correct 14,3% (13/91) van de issues opgelost. Dit komt overeen met de succespercentages gerapporteerd in soortgelijke studies voor andere talen, wat suggereert dat JETO-Bench een betrouwbare benchmark is.
Fault Localization: In 27,5% van de gevallen wijzigde OpenHands de juiste code-locatie, maar slaagde het er niet in om een semantisch correcte patch te produceren, wat benadrukt dat fault localization een belangrijk gebied voor verbetering is.
Test Schaarste: De studie toonde aan dat open-source Java-projecten grotendeels een tekort hebben aan tests die uitvoeringstijdverbeteringen demonstreren. Slechts 15% van de geverifieerde ETIPs bevatte JMH-benchmarks, en bestaande JUnit-tests detecteerden zelden statistisch significante prestatieverschillen.

Resultaten en Bevindingen

Precisie: Handmatige analyse van 50 willekeurig geselecteerde geïdentificeerde ETIPs bevestigde een precisiepercentage van 96% voor het identificatieproces van JETO-Mine.
Schaalbaarheid: De statische analyse verwerkte 1,7 miljoen commits in 478 uur (ongeveer 20 dagen) tegen een kostenpost van $5,33 voor LLM-filtering. De dynamische analyse verwerkte 660 ETIPs in 152 uur, met een mediane Docker-image build-tijd van 34 minuten en een mediane grootte van 790 MB.
Agent Prestaties: OpenHands behaalde een succespercentage van 14,3%, waarbij 22% van de gegenereerde patches succesvol bouwde en tests doorstond. De evaluatie harness filterde ineffectieve patches effectief uit (slechts 20/91 slaagde voor alle tests), wat de waarde van executie-gebaseerde feedback bevestigt.
Test Generatie Gap: Een voorlopige poging om OpenHands te gebruiken om ETIP detector tests te genereren voor de 91 gevallen, slaagde slechts in één instantie, wat de moeilijkheid onderstreept van het genereren van tests die prestatieverbeteringen betrouwbaar kunnen meten.

Betekenis en Claims

Het artikel claimt dat JETO-Mine en JETO-Bench een cruciaal gat in het landschap van automated repair opvullen door de eerste configureerbare, reproduceerbare benchmark te bieden voor Java uitvoeringstijdverbeteringen.

Reproduceerbaarheid: Door gebruik te maken van Docker en statistische testen om JVM-volatiliteit te mitigeren, zorgt de benchmark ervoor dat prestatieclaims objectief en reproduceerbaar zijn, in tegenstelling tot eerdere statische datasets.
Uitbreidbaarheid: In tegenstelling tot vaste datasets, stelt JETO-Mine de community in staat om de benchmark continu uit te breiden met nieuwe patches volgens specifieke onderzoeksbehoeften.
Onderzoeksmogelijkheid: De bevindingen wijzen op een aanzienlijk gat in de huidige testpraktijken: de schaarste aan tests die uitvoeringstijdverbeteringen verifiëren. De auteurs stellen dat dit een veelbelovende kans biedt voor toekomstig onderzoek naar automatische generatie van tests voor prestatieoptimalisatie.
Bruikbaarheid van de Benchmark: De evaluatie van OpenHands toont aan dat JETO-Bench effectief is voor het beoordelen van de capaciteiten en beperkingen van geavanceerde coding agents op Java-prestatietaken, wat de resultaten weerspiegelt die gezien zijn bij andere talen.

De auteurs concluderen dat hoewel huidige agents beperkt succes laten zien bij het oplossen van prestatieproblemen, het bestaan van een rigoureuze, reproduceerbare benchmark zoals JETO-Bench essentieel is voor het stimuleren van toekomstige vooruitgang in automatische prestatieoptimalisatie en testgeneratie.