CPython’ın peephole optimizasyonu, koşulsuz bir atlamanın (JUMP_ABSOLUTE, JUMP_FORWARD, RETURN_VALUE, RAISE_VARARGS) ardından başka dallardan herhangi bir giriş noktası olmayan ulaşılamaz blokları tespit etmek için bytecode’u tarar. Tanımlandığında, bu ölü talimatları kaldırarak önbellek baskısını azaltır ve talimat yoğunluğunu artırır.
Python’ın istisna işleme tabloları, döngü yapıları ve koşullu atlamalar, hedef konumlarını kod nesnesinin co_code dizisine göre mutlak byte ofsetleri olarak depoladığından, optimizasyoncu, her hayatta kalan talimattan önce kaç byte silindiğini takip eden bir taşınma haritası oluşturmak zorundadır. Daha sonra, tüm atlama talimatlarını ve istisna işleyici aralıklarını gözden geçirerek, hedef konumdaki birikimli silme sayısını çıkararak hedef ofsetlerini ayarlar. Bu, SETUP_FINALLY blokları, FOR_ITER döngüleri ve kullanıcı tanımlı atlamaların doğru opcode’a indiğinden emin olur, önceki bytecode sıkıştırılmış olsa bile.
Bir veri boru hattı ekibi, ETL aracının başlangıç betiğinde if DEBUG: bayrakları ile korunan geniş hata ayıklama günlükleme bloklarının bulunduğunu fark etti; burada DEBUG, False olarak ayarlanmış bir modül seviyesinde sabitti. Koşul statik olarak yanlış olmasına rağmen, derlenmiş bytecode hala derlemeden sonra günlükleme mantığını içeriyordu, bu da .pyc dosya boyutunu %40 artırdı ve üretim sunucularında talimat önbellek yerelliğini hafifçe düşürdü.
Üç farklı yaklaşımı değerlendirdiler.
İlk olarak, üretim öncesi hata ayıklama kodunu silmek için bir C ön işleyici veya Jinja2 şablonlaması kullanmayı düşündüler. Bu yaklaşım, üretimde sıfır hata ayıklama bytecode’u garanti ederdi, ancak karmaşık bir derleme adımı bağımlılığı ekledi ve geliştirme ile üretim kod tabanları arasında ince farklılıklara yol açarak, kaynak kodu artık çalışan bytecode ile uyuşmadığında üretim sorunlarının hata ayıklamasını zorlaştırdı.
İkinci olarak, tüm hata ayıklama bloklarını bir alt modülde ayrı işlevler haline getirmeyi değerlendirdiler, çağrılmamış işlevlerin yüklenmeyeceğini umarak. Ancak, Python’ın import sistemi tüm modülleri bir kerede derler ve çağrılmamış işlevler modülün sözlüğünde kod nesneleri olarak kalır; peephole optimizasyonu, prosedürler arası ölü kod ortadan kaldırma yapmadıkları için bytecode boyutu değişmeden kaldı.
Üçüncü olarak, CPython’ın derleme boru hattını incelediler ve peephole optimizasyonunun, derleyicinin bloğun etrafında koşulsuz bir atlama ürettiği için if False: yapılarının arkasındaki kodu otomatik olarak kaldırdığını keşfettiler; peephole geçişi ulaşılamaz kuyruklu kodu temizler. dis modülü ile doğrulama yaparak, RETURN_VALUE veya JUMP_FORWARD talimatlarının arkasında ölü kod olmadığını doğruladılar ve bu optimizasyonun aktif olduğunu onayladılar. Bu yerleşik mekanizmaya güvenmeyi tercih ettiler ve DEBUG’nin bir runtime hesaplanan değişken yerine literal False olmasını sağladılar; bu da derlenmiş bytecode boyutunu %35 oranında azaltarak ek bir araç kullanmadan elde edildi.
Peephole optimizasyonu, önceki atlama hedefine bir hesaplanan atlama talimatı tarafından adreslenmesi durumunda neden ulaşılamaz kodu kaldırmayı reddediyor?
Hesaplanan atlamalar, yığın üzerindeki bir değere dayanarak hedeflerini çalışma zamanında belirler, örneğin MATCH ifadelerinde veya dinamik yönlendirme desenlerinde. Optimizasyoncu hangi ofsetlerin hedeflenebileceğini statik olarak bilemeyeceğinden, herhangi bir talimatın bir giriş noktası olabileceğini temkinli bir şekilde varsaymak zorundadır. Bu nedenle, yalnızca koşulsuz atlamaların statik analiziyle kesin olarak ulaşılamaz olduğu kanıtlanan kodları siler ve dinamik yönlendirme için hedef olabilecek her bloğu korur.
NOP talimatlarının atlama yer tutucuları olarak silinmesi durumunda istisna işleyici tablolarını (co_exceptiontable) optimizasyoncu nasıl ele alır?**
Derleyici, henüz bilinmeyen ileri konumlara atlamalar oluşturduğunda, genellikle yer tutucular veya dolgu olarak NOP (işlem yapmama) talimatları çıkarır ve ardından atlama hedeflerini daha sonra düzeltir. Peephole optimizasyonu sırasında bu NOP’lar, yer tasarrufu sağlamak için kaldırılır. Optimizasyoncu, orijinal ve son ofsetler arasında çift yönlü bir eşleme tutar. İstisna tablosunu işlerken—try/except blokları için start, end ve handler ofsetlerini depolar—her girişe silinen byte’ların birikimli delta’sını uygular. Eğer bir NOP bir istisna aralığı içinde ise, onun kaldırılması end ofsetini sola kaydırır ve korunan bytecode aralığının doğru kalmasını sağlar ve istisnaların doğru sınırda yakalanmasını temin eder.
Peephole optimizasyonunun C derleyicilerinde görüldüğü gibi bağımsız talimatları yeniden sıralayarak boru hattı verimliliğini artırmasını ne engeller?
Python’ın bytecode’u, değerlendirme yığını anlamsal ve izleme numarası tablolarıyla sıkı bir şekilde bağlıdır. Talimatları yeniden sıralamak—örneğin, bir LOAD_CONST talimatını bir LOAD_NAME talimatının önüne almak—istisna meydana geldiğinde yığın durumunu değiştirebilir, izleme geri dönüşlerinde rapor edilen satır numarasını değiştirebilir veya yorumlayıcı döngüsü için gerekli yığın derinliği değişkenliklerini ihlal edebilir. Ayrıca, Python çerçeve nesnelerinin f_lasti (talimat işaretçisi) üzerinde inceleme yapılmasına izin verdiğinden, rastgele yeniden sıralama, belirli bir kaynağa ofset eşleme gereksinimi olan hata ayıklayıcılar ve profil oluşturucu araçlar için problemlere sebep olabilir. Böylece, optimizasyoncu yalnızca ulaşılamaz kodu silme ve atlamaları yeniden yönlendirme işlemleriyle kısıtlı kalır; yürütülebilir talimatların göreceli sırasını değiştirmeden.