Misleading Microbenchmarks on the Java Virtual Machines
Dit artikel toont aan dat microbenchmarks op de JVM, zelfs bij naleving van de richtlijnen van het Java Microbenchmark Harness (JMH), misleidende prestatieresultaten kunnen opleveren door onrealistische uitvoeringsprofielen te induceren die agressieve, niet-representatieve optimalisaties activeren, en het stelt uitgebreide richtlijnen voor om deze problemen te mitigeren.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.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 chef-kok bent die moet beslissen welke van twee nieuwe messen scherper is. Je stelt een test op waarbij je exact hetzelfde stuk papier 1.000 keer achter elkaar snijdt, zonder dat er iemand anders in de keuken is, zonder andere taken en waarbij het papier altijd even dik is.
Op basis van deze test lijkt Mes A ongelooflijk snel. Maar in de echte wereld, waar je uien snijdt, tomaten in plakjes snijdt en door hard biefstuk snijdt, allemaal tegelijk, kan Mes A eigenlijk langzamer zijn dan Mes B.
Dit is precies wat het artikel "Misleading Microbenchmarks on the Java Virtual Machines" betoogt dat er gebeurt met softwareontwikkelaars wanneer ze hun code testen.
Het Probleem: De "Steriele" Testkeuken
Ontwikkelaars gebruiken vaak een hulpmiddel genaamd JMH (Java Microbenchmark Harness) om kleine stukjes code te testen. Ze willen weten: "Is mijn nieuwe manier om wiskunde te doen sneller dan de oude manier?"
Het artikel noemt de omgeving waarin deze tests worden uitgevoerd een "steriele omgeving". Het is als een laboratorium waar:
- Slechts één taak plaatsvindt: De code wordt geïsoleerd getest, zonder andere programma's die draaien.
- De invoer nooit verandert: De code krijgt keer op keer exact dezelfde gegevens aangeleverd.
- De computer "lui" wordt: De Java Virtual Machine (JVM)—de motor die Java-code uitvoert—is slim. Hij observeert wat je doet en probeert te raden wat je als volgende gaat doen om dingen sneller te maken. Dit heet speculatieve optimalisatie.
De Valstrik: De "Te Gespecialiseerde" Chef
Hier zit de adder onder het gras: Omdat de test zo "steriel" is (herhalend en geïsoleerd), raakt de motor van de JVM in de war. Hij ziet dat de code elke keer precies hetzelfde doet en denkt: "Ah! Deze code krijgt altijd een 5-inch stuk papier. Ik bouw een aangepaste machine die alleen 5-inch stukken perfect snijdt."
De motor bouwt een hooggespecialiseerde, supersnelle versie van de code voor dat één specifieke scenario.
Het Resultaat: De test zegt: "Wow, deze code is 40% sneller!"
De Realiteit: In een echte applicatie krijgt de code stukken papier van allemaal verschillende maten. De gespecialiseerde machine valt uiteen, en de code draait eigenlijk langzamer dan de originele, flexibelere versie.
Het artikel toont drie specifieke voorbeelden waar dit bedrog optreedt:
1. De "Eén-Maat-Is-Alles" Hash Code
- De Test: Een ontwikkelaar creëert een nieuwe manier om een "vingerafdruk" te berekenen voor een lijst met getallen. In de test voert hij er alleen lijsten met precies 10 getallen aan.
- De Illusie: De nieuwe code ziet er fantastisch uit omdat de motor hem specifiek heeft geoptimaliseerd voor lijsten van 10.
- De Realiteit: Wanneer de code in een echte app wordt gebruikt met lijsten van 3, 50 of 100 getallen, is de "gespecialiseerde" code onhandig en traag. De oude, saaie code was eigenlijk de hele tijd al beter.
2. De Stream API (De Assemblagelijn)
- De Test: Ontwikkelaars testen een moderne manier om gegevens te verwerken (Streams genoemd) door slechts één specifieke query geïsoleerd uit te voeren.
- De Illusie: De motor ziet deze ene query en optimaliseert de assemblagelijn perfect voor die query.
- De Realiteit: Echte apps voeren duizenden verschillende queries uit. De "perfecte" assemblagelijn van de motor kan niet omgaan met de variatie, en de prestaties dalen. Het artikel vond dat code die in de test 41% sneller leek, in het echt eigenlijk langzamer was.
3. De "Onfaire" Vergelijking van Collecties
- De Test: Een ontwikkelaar wil bewijzen dat zijn nieuwe "List" of "Map" (gegevensopslagtools) sneller is dan de standaardtools die in Java zijn ingebouwd.
- De Illusie: Hij voert de test uit, en zijn nieuwe tool wint.
- De Realiteit: De standaard Java-tools waren al "opwarmen" en werden geoptimaliseerd voordat de test zelfs maar begon, omdat het Java-systeem ze gebruikt om zichzelf op te zetten. De nieuwe tool krijgt een "frisse start" in de steriele test, terwijl de oude tool wordt belast door zijn geschiedenis. Het is als een race waarbij één renner start op de startlijn, en de andere renner gedwongen wordt eerst een rondje om het circuit te rennen, maar de timer pas start wanneer ze beiden de finishlijn kruisen. Het artikel toont aan dat wanneer je dit onrechtvaardige aspect corrigeert, de "nieuwe" tool vaak niet echt sneller is.
De Oplossing: De Test "Verontreinigen"
Het artikel suggereert een simpele oplossing: Laat de test niet te schoon zijn.
Voordat je de snelheid meet, moet je de omgeving "verontreinigen". Dit betekent dat je de code uitvoert met veel verschillende invoer en scenario's voordat je de timer start.
- Analogie: Voordat je je mes meet, snijd een wortel, een aardappel, een tomaat en een stuk hard vlees. Laat de motor de variatie zien.
- Resultaat: De motor stopt met proberen een machine te bouwen voor slechts één ding. Hij bouwt een veelzijdige machine die alles goed aankan. Nu weerspiegelen de testresultaten daadwerkelijk wat er in de echte wereld zal gebeuren.
De Conclusie
Als je je code test in een perfecte, geïsoleerde bubbel waar niets ooit verandert, kun je een resultaat krijgen dat er geweldig uitziet maar een leugen is. Om de waarheid te krijgen, moet je je code testen in een rommelige, realistische omgeving waar dingen veranderen, net zoals in het echte leven.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.