Tree-shaking, Bahçecilik Açısından Yanıltıcı Algoritma (2023)

 (wingolog.org)
2 puan yazan GN⁺ 2024-04-15 | 1 yorum | WhatsApp'ta paylaş

WebAssembly'nin sınırları ve Tree-shaking'in önemi

  • WebAssembly, büyük ilgi ve beklentilere rağmen web'de yalnızca sınırlı bir başarı elde etti

    • Photoshop gibi başarılı örnekler olsa da genel olarak WebAssembly kullanan proje sayısı fazla değil
    • Özellikle DOM'un yoğun kullanıldığı uygulamalarda WebAssembly uygun değil
    • Bunun başlıca nedenlerinden biri JavaScript ile WebAssembly'nin programlama modelleri arasındaki fark

  • WebAssembly, C veya Rust gibi dillerin dışında kayda değer bir başarı yakalayamadı

    • C# gibi dillerde garbage collector gibi runtime bileşenlerini de birlikte sunma zorunluluğu gibi bir zorluk var
    • Ancak referans tipleri ve garbage collection desteği sunan yeni WebAssembly özelliklerinin yakında gelmesi beklendiğinden durumun iyileşmesi umuluyor

Derleyicinin kod optimizasyon yeteneği, WebAssembly başarısının anahtarı

  • WebAssembly'nin web'de başarılı olabilmesi için derleyicinin küçük ve verimli kod üretebilmesi gerekiyor

    • Birkaç kilobayt civarında küçük dosya boyutlarını korumak önemli
    • Aksi halde abartılı beklentilere veya belirli bir kullanıcı tabanına dayanmak dışında seçenek kalmıyor

  • JavaScript dünyasında bundler'lar vb. araçlarla kod boyutu optimizasyonu yapılıyor

    • Tree-shaking, programda gerçekten kullanılan fonksiyonların ve veri tiplerinin dahil edilmesini sağlayan bir teknik

  • Tree-shaking, bahçecilik ve algoritma açısından pek uygun bir mecaz olmasa da yaygın olarak kullanılan bir terim

Diğer dillerde Tree-shaking'in durumu

  • Go veya Python gibi runtime'ı ağır dillerde Tree-shaking henüz iyi optimize edilmiş değil

    • En basit Go programı bile WebAssembly'ye derlendiğinde 2MB'tan büyük oluyor
    • Python'un Pyodide'i de yaklaşık 20MB dosya indirilmesini gerektiriyor

  • Bunun nedeni sunucu ortamında binary boyutunun büyük bir sorun olmaması

    • Mobil gibi kısıtlı ortamlar için MicroPython, TinyGo gibi hafifletilmiş toolchain'ler ayrıca geliştiriliyor

  • Web ortamına yönelik dil implementasyonları, mevcut olanlardan kaçınılmaz olarak farklı olmak zorunda

    • Çünkü DOM ile etkileşim kurmak başlı başına alışılmadık bir ortam
    • ClojureScript, örneğin Clojure ile farklarını ayrı belgelerde dokümante ediyor

Tree-shaking algoritmasına dair tartışma

  • Yazarın geliştirmekte olduğu Hoot Scheme derleyicisi şu anda yaklaşık 70KB Wasm kodu üretiyor

    • Yalnızca fonksiyon (procedure) tanımlarını dahil etmek görece kolay
    • Ancak aşağıdaki gibi bazı zor noktalar var

  • letrec* değerlendirme modelinde binding'ler hem özyinelemeli hem sıralı olduğundan derleyicinin analiz etmesi zorlaşıyor

    • Record type'larda ise vtable callback'leri çok sayıda kodun canlı kalmasına neden oluyor

  • display gibi yüksek derecede polymorphic fonksiyonlar kullanıldığında ilişkili birçok kod da pakete giriyor

    • write-string gibi daha somut fonksiyonları kullanmak daha iyi

  • En iyi Tree-shaking için flow analysis gerekli

    • display'e bitvector argümanının geçmediği bilinebilirse ilgili kod kaldırılabilir

  • Python'da dynamic dispatch, __getattr__ gibi dinamik özellikler yüzünden iş daha da zor

    • Python'un modül yapısı da Tree-shaking'i karmaşıklaştıran etkenlerden biri

Özet

  • GC desteği sayesinde WebAssembly'de JavaScript dışındaki dillerle DOM programlama mümkün hale geliyor
  • Ancak ortaya çıkan çıktının boyutunu yeterince küçük tutmak için her dilin toolchain'ine önemli yatırım gerekiyor
  • Tree-shaking algoritmalarını uygulayan ayrı toolchain'lerin geliştirilmesi ve standart kütüphane optimizasyonu gibi çalışmalar gerekli

GN⁺ görüşü

  • WebAssembly GC desteği kazandıkça web geliştirmede farklı diller kullanılabilir hale geliyor, ancak mevcut dil toolchain'lerini olduğu gibi taşımak çok zor görünüyor. Web ortamına özel dil implementasyonları ve optimizasyon tekniklerinin geliştirilmesi gerekecek gibi duruyor.

  • Tree-shaking'in dinamik tiplemeli dillerde iyi çalışabilmesi için statik analiz şart gibi görünüyor. Ancak Python gibi diller çok sayıda dinamik özelliğe sahip olduğu için bu kolay olmayacaktır. Hatta en baştan statik analize daha elverişli yeni bir dil tasarlamak da bir seçenek olabilir.

  • Hoot veya TinyGo gibi deneysel projeler iyi birer referans olabilir. Ancak bu tür projeleri gerçek ürünlerde kullanmak için henüz erken olabilir. Kademeli iyileştirme dışında pek seçenek yok gibi görünüyor.

  • Performans hassasiyeti düşük, hızlı geliştirmenin önemli olduğu projelerde Pyodide gibi çözümler düşünülebilir. Ancak kullanıcı deneyiminin kritik olduğu ürünlerde şu anda en iyi seçenek hâlâ JavaScript gibi görünüyor.

  • Tree-shaking benzeri bir özelliğin doğrudan WebAssembly'ye eklenmesi de düşünülebilir. Ancak gereksinimler dile göre değiştiği için bu kolay olmaz. Ayrıca Tree-shaking'i iyi destekleyen bir dil ortaya çıkarsa, doğrudan o dille geliştirme yapmak daha avantajlı da olabilir. WebAssembly ile programlama dilleri arasındaki görev paylaşımının nasıl şekilleneceği merak konusu.

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-15
Hacker News yorumu

Özetle şöyle:

  • OpenEtG projesinde, Rust ile yazılmış WASM ikili dosyasının boyutunu 400KB'ın altında tutmak için şu çabalar gösteriliyor
    • float yerine sabit noktalı aritmetik kullanımı
    • HashMap yerine Vec kullanımı
    • string kullanımını en aza indirme
    • küçük bir allocator (talc) kullanımı
    • bağımlılıkları en aza indirme (rand, fxhash kullanılıyor)
    • generic çeşitliliğinden kaçınma
    • boyutu gözeten algoritma tasarımı
  • Tree-shaking yanlış adlandırılmış bir terim ve Virgil derleyicisinde buna Reachability Analysis deniyor. Derleme sürecinde main giriş noktasından tarama yapılarak yalnızca erişilebilir kod son ikili dosyaya dahil ediliyor.
  • WasmGC sayesinde Java ve Kotlin, 2-3KB kadar küçük WASM ikili dosyaları üretebiliyor. Ancak API seçiminde dikkatli olmak gerekiyor.
  • WASM ile DOM manipülasyonu hâlâ JS'ye bağımlı.
  • Tree Shaking teriminin ortaya çıkma nedeni, Dead Code Elimination kavramının çok daha eskiden beri var olması.
  • WASM'daki kod boyutu sorunu, dil çalışma zamanı ile standart kütüphanelerin birlikte paketlenmek zorunda olmasından kaynaklanıyor.
  • Bunu çözmek için paylaşımlı kütüphaneler ve dinamik bağlama düşünülebilir.
    • Pyodide, dinamik bağlamayı destekleyen temsilî bir örnek
    • Tarayıcı popüler dil çalışma zamanlarını önceden yüklerse, web sayfaları bu çalışma zamanını paylaşabilir
  • Zig dili, küçük WASM ikili dosyaları üretmeye uygun. Ancak 100KB'ın altındaysa boyut önemli bir unsur değil.
  • Yerleşik GC her uygulama için önemli değil ve GC'siz web uygulamaları yapmak daha iyi.
  • WASM kullanan uygulamaların başarısında temel etken hâlâ performans artışı.
  • ClojureScript, TypeScript, ReasonML gibi JS'ye derlenen diller sayesinde uzun zamandır JS dışındaki dillerle DOM programlama yapılıyordu.
  • asm.js ve emscripten ile, WASM'den önce de C tabanlı diller web için derlenip kullanılıyordu.
  • Google Maps ve Google Earth, WASM kullanan temsilî uygulamalardan bazıları.