De peephole-optimizer van CPython scant de bytecode op onbereikbare blokken—sequenties van instructies die volgen op een onvoorwaardelijke sprong (JUMP_ABSOLUTE, JUMP_FORWARD, RETURN_VALUE, RAISE_VARARGS) die geen toegangspunten van andere takken missen. Wanneer ze zijn geïdentificeerd, verwijdert het deze dode instructies om de cache-druk te verminderen en de instructiedichtheid te verbeteren.
Omdat de excepthandlingtabellen van Python, lusconstructies en voorwaardelijke sprongen doelplaatsen opslaan als absolute byte-offsets in de co_code reeks van het codeobject, moet de optimizer een relocatiekaart construeren die bijhoudt hoeveel bytes vóór elke overlevende instructie zijn verwijderd. Vervolgens doorloopt het alle spronginstructies en uitzonderingshandlerbereiken, en past het hun doel-offsets aan door de cumulatieve verwijderingslast op de doelpositie af te trekken. Dit zorgt ervoor dat SETUP_FINALLY blokken, FOR_ITER lussen, en door gebruikers gedefinieerde sprongen op de juiste opcode terechtkomen, zelfs nadat de voorafgaande bytecode is gecompacteerd.
Een datastroomteam merkte op dat hun ETL-hulpprogramma's opstartscript uitgebreide foutopsporingslogboekblokken bevatte die werden bewaakt door if DEBUG: vlaggen, waarbij DEBUG een constante op module-niveau was ingesteld op False. Ondanks dat de voorwaarde statisch onwaar was, bevatte de gecompileerde bytecode nog steeds de logica van het loggen na compilatie, wat de grootte van het .pyc bestand met 40% verhoogde en de lokale instructiecache op de productie-servers licht degradeerde.
Ze hebben drie verschillende benaderingen geëvalueerd.
Als eerste, overwegen ze om een C-preprocessor of Jinja2-templating te gebruiken om foutopsporingscode vóór de implementatie te strippen. Deze benadering zou nul foutopsporingsbytecode in productie garanderen, maar introduceerde een complexe build-stapafhankelijkheid en risico op subtiele afwijkingen tussen ontwikkelings- en productiecodebases, waardoor het debuggen van productieproblemen moeilijker werd, waar de broncode niet meer overeenkwam met de draaiende bytecode.
Tweede, evalueren ze het refactoren van alle foutopsporingsblokken in aparte functies in een submodule, in de hoop dat niet-opgeroepen functies niet zouden worden geladen. Echter, het importmechanisme van Python compileert hele modules tegelijk, en niet-opgeroepen functies blijven als codeobjecten in de dictionary van de module staan; de peephole-optimizer voert geen interprocedural dead code eliminatie uit, waardoor de bytecodgrootte onveranderd bleef.
Derde, onderzochten ze de compilatiepipeline van CPython en ontdekten dat de peephole-optimizer automatisch code verwijdert die volgt op if False: constructies omdat de compiler een onvoorwaardelijke sprong rond het blok genereert, en de peephole-pass de onbereikbare staart verwijdert. Door te verifiëren met de dis module dat RETURN_VALUE of JUMP_FORWARD gevolgd werd door geen dode code, bevestigden ze dat de optimalisatie actief was. Ze kozen ervoor om op dit ingebouwde mechanisme te vertrouwen, en zorgden ervoor dat DEBUG een letterlijke False was in plaats van een op runtime berekende variabele, wat de gecompileerde bytecodesgrootte met 35% verminderde zonder extra hulpmiddelen.
Waarom weigert de peephole-optimizer om onbereikbare code te verwijderen wanneer het voorafgaande sprongdoel wordt aangeduid door een berekende spronginstructie?
Berekende sprongen bepalen hun bestemming tijdens runtime op basis van een waarde op de stack, zoals in MATCH-verklaringen of dynamische dispatchpatronen. Aangezien de optimizer niet statisch kan weten welke offsets misschien gericht zijn, moet het conservatief aannemen dat elke instructie een toegangspunt kan zijn. Daarom verwijdert het alleen code die aantoonbaar onbereikbaar is via statische analyse van onvoorwaardelijke sprongen en controleflowgrafen, waarbij elke blok wordt bewaard die het doel van een dynamische dispatch zou kunnen zijn om ongewenst gedrag te voorkomen.
Hoe behandelt de optimizer excepthandlertabellen (co_exceptiontable) wanneer het NOP instructies verwijdert die als sprongplaatsvervangers worden gebruikt?
Wanneer de compiler sprongen genereert naar vooruitgaande locaties die nog niet bekend zijn, genereert het vaak NOP (no-operation) instructies als tijdelijke of opvullende plaatsvervangers, en patcht vervolgens sprongdoelen later. Tijdens peephole-optimalisatie worden deze NOP s verwijderd om ruimte te besparen. De optimizer behoudt een bidirectionele mapping tussen oorspronkelijke en eindoffsets. Wanneer het de uitzonderingstabel verwerkt—die start, end, en handler offsets voor try/except blokken opslaat—past het de cumulatieve delta van verwijderde bytes toe op elke invoer. Als een NOP binnen een uitzondering bereik valt, verschuift zijn verwijdering de end offset naar links, waardoor het beschermde bytecode-bereik accuraat blijft en uitzonderingen op de juiste grenzen worden gevangen.
Wat voorkomt dat de peephole-optimizer onafhankelijke instructies herschikt om de efficiëntie van de pipeline te verbeteren, zoals te zien in C-compilers?
De bytecode van Python is nauw verbonden met de evaluatiestack-semantiek en regelnummer-tabellen die worden gebruikt voor het genereren van traceback. Het herschikken van instructies—bijvoorbeeld het verplaatsen van een LOAD_CONST vóór een LOAD_NAME—zou de toestand van de stack kunnen veranderen wanneer een uitzondering optreedt, waardoor het gerapporteerde regelnummer in traceback verandert of de invarianten van de stackdiepte die door de interpreterlus vereist zijn schenden. Bovendien, omdat Python introspectie van frame-objecten en f_lasti (de instructiepointer) toestaat, zou willekeurige herschikking debuggers en profilers die afhankelijk zijn van deterministische offset-naar-bron-mapping kunnen breken. Daarom is de optimizer beperkt tot het verwijderen van onbereikbare code en het omleiden van sprongen zonder de relatieve volgorde van uitvoerbare instructies te veranderen.