Tree-shaking, बागवानी की दृष्टि से भटकाने वाला algorithm (2023)

 (wingolog.org)
2 पॉइंट द्वारा GN⁺ 2024-04-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

WebAssembly की सीमाएँ और Tree-shaking का महत्व

  • काफी रुचि और उम्मीदों के बावजूद WebAssembly को वेब पर केवल सीमित सफलता मिली है

    • Photoshop जैसे सफल उदाहरण हैं, लेकिन कुल मिलाकर WebAssembly का उपयोग करने वाले प्रोजेक्ट बहुत अधिक नहीं हैं
    • खासकर DOM का बहुत अधिक उपयोग करने वाले apps में WebAssembly उपयुक्त नहीं है
    • JavaScript और WebAssembly के programming model में अंतर इसके प्रमुख कारणों में से एक है

  • C या Rust जैसी भाषाओं के अलावा WebAssembly को बड़ी सफलता नहीं मिली है

    • C# जैसी भाषाओं में garbage collector जैसे runtime को साथ में उपलब्ध कराना पड़ता है, जो असुविधाजनक है
    • लेकिन WebAssembly की नई सुविधाएँ, जो reference types और garbage collection को support करती हैं, जल्द आने वाली हैं, इसलिए स्थिति में सुधार की उम्मीद है

compiler की code optimization क्षमता WebAssembly की सफलता की कुंजी

  • वेब पर WebAssembly की सफलता के लिए compiler को छोटा और efficient code generate करने में सक्षम होना होगा

    • कुछ kilobytes के भीतर छोटा file size बनाए रखना महत्वपूर्ण है
    • ऐसा न होने पर केवल hype या किसी खास user base पर निर्भर रहना पड़ेगा

  • JavaScript की दुनिया में bundler आदि के जरिए code size optimization किया जा रहा है

    • Tree-shaking वह तकनीक है जिसमें program में वास्तव में उपयोग होने वाले functions और data types ही शामिल किए जाते हैं

  • Tree-shaking horticultural और algorithmic, दोनों दृष्टियों से अनुपयुक्त रूपक है, फिर भी यह व्यापक रूप से इस्तेमाल होने वाला शब्द है

अन्य भाषाओं में Tree-shaking की स्थिति

  • Go या Python जैसी भारी runtime वाली भाषाओं में अभी Tree-shaking अच्छी तरह optimized नहीं है

    • सबसे सरल Go program भी WebAssembly में compile करने पर 2MB से बड़ा हो जाता है
    • Python का Pyodide भी लगभग 20MB की file download करवाता है

  • server environment में binary size बहुत बड़ी समस्या नहीं होती

    • mobile जैसे सीमित environments के लिए MicroPython, TinyGo जैसे lightweight toolchains अलग से विकसित किए गए हैं

  • वेब environment के लिए language implementations का पारंपरिक implementations से अलग होना लगभग अनिवार्य है

    • क्योंकि DOM के साथ interaction करना अपने आप में एक असामान्य environment है
    • ClojureScript के मामले में Clojure से इसके अंतर को अलग से document किया गया है

Tree-shaking algorithm पर चर्चा

  • लेखक द्वारा विकसित किया जा रहा Hoot Scheme compiler इस समय लगभग 70KB का Wasm code generate कर रहा है

    • केवल function (procedure) definitions को शामिल करना अपेक्षाकृत आसान है
    • लेकिन नीचे जैसी कुछ कठिन समस्याएँ हैं

  • letrec* evaluation model में bindings recursive भी होती हैं और ordered भी, इसलिए compiler के लिए उनका analysis कठिन हो जाता है

    • record type के मामले में vtable callbacks बहुत सारा code जीवित बनाए रखते हैं

  • display जैसी अत्यधिक polymorphic function का उपयोग करने पर उससे संबंधित बहुत सारा code शामिल हो जाता है

    • write-string जैसी specific function का उपयोग करना बेहतर है

  • सर्वोत्तम Tree-shaking के लिए flow analysis की आवश्यकता होती है

    • यदि यह पता हो कि display को bitvector argument नहीं दिया जाता, तो संबंधित code हटाया जा सकता है

  • Python में dynamic dispatch, __getattr__ जैसी dynamic सुविधाओं के कारण यह और कठिन हो जाता है

    • Python की module structure भी Tree-shaking को जटिल बनाने वाला एक कारण है

सारांश

  • GC support के कारण WebAssembly में JavaScript के अलावा अन्य भाषाओं से भी DOM programming संभव हो रही है
  • लेकिन output का आकार पर्याप्त रूप से छोटा बनाने के लिए हर भाषा के toolchain में काफी निवेश की आवश्यकता है
  • Tree-shaking algorithm लागू करने वाले अलग toolchain के विकास और standard library optimization जैसी चीज़ों की ज़रूरत है

GN⁺ की राय

  • WebAssembly में GC support आने से वेब development में विभिन्न भाषाओं का उपयोग संभव हुआ है, लेकिन मौजूदा भाषाओं के toolchain को ज्यों का त्यों लाना बहुत कठिन लगता है। लगता है कि वेब environment के लिए विशेष language implementation और optimization तकनीकों का विकास करना होगा।

  • dynamic typing वाली भाषाओं में Tree-shaking को अच्छी तरह काम कराने के लिए static analysis अनिवार्य लगता है। लेकिन Python जैसी भाषाओं में dynamic सुविधाएँ बहुत अधिक हैं, इसलिए यह आसान नहीं होगा। बेहतर static analysis के अनुकूल नई भाषा शुरू से बनाना भी एक तरीका हो सकता है।

  • Hoot या TinyGo जैसे experimental projects अच्छे reference हो सकते हैं। लेकिन ऐसे projects को वास्तविक products में लागू करना अभी शायद जल्दबाज़ी होगी। लगता है कि इसे धीरे-धीरे सुधारना ही पड़ेगा।

  • यदि project performance-sensitive नहीं है और तेज़ development अधिक महत्वपूर्ण है, तो Pyodide जैसी चीज़ आज़माई जा सकती है। लेकिन यदि product में user experience अधिक महत्वपूर्ण है, तो फिलहाल JavaScript ही सबसे अच्छा विकल्प लगता है।

  • WebAssembly में Tree-shaking जैसी सुविधा को खुद शामिल करने के बारे में भी सोचा जा सकता है। लेकिन भाषाओं के अनुसार आवश्यकताएँ अलग होती हैं, इसलिए यह आसान नहीं होगा। और यदि Tree-shaking को अच्छी तरह support करने वाली कोई भाषा आ जाए, तो शायद उसी भाषा में coding करना अधिक लाभकारी हो। WebAssembly और programming languages के बीच भूमिकाओं का बँटवारा कैसे होगा, यह दिलचस्प रहेगा।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-15
Hacker News की राय

संक्षेप में यह इस प्रकार है:

  • OpenEtG प्रोजेक्ट में Rust में लिखे गए WASM बाइनरी का आकार 400KB से कम रखने के लिए निम्न प्रयास किए गए
    • float की जगह fixed-point arithmetic का उपयोग
    • HashMap की जगह Vec का उपयोग
    • strings का उपयोग न्यूनतम रखना
    • छोटे allocator (talc) का उपयोग
    • dependencies को न्यूनतम रखना (rand, fxhash ही उपयोग)
    • generic diversity से बचना
    • आकार को ध्यान में रखकर algorithm design करना
  • Tree-shaking गलत naming है, और Virgil compiler में इसे Reachability Analysis कहा जाता है. compile process में main entry point से खोजकर केवल reachable code को अंतिम बाइनरी में शामिल किया जाता है.
  • WasmGC की वजह से Java और Kotlin 2-3KB के छोटे WASM बाइनरी बना सकते हैं. लेकिन API selection में सावधानी ज़रूरी है.
  • WASM का उपयोग करके DOM manipulation अभी भी JS पर निर्भर है.
  • Tree Shaking शब्द इसलिए आया क्योंकि Dead Code Elimination बहुत पहले से मौजूद था.
  • WASM में code size की समस्या इसलिए आती है क्योंकि language runtime और standard library दोनों को bundle करना पड़ता है.
  • इसे हल करने के लिए shared libraries और dynamic linking पर विचार किया जा सकता है.
    • Pyodide dynamic linking को support करने का एक प्रमुख उदाहरण है
    • अगर browser लोकप्रिय language runtimes को पहले से लोड करे, तो web pages उस runtime को share कर सकते हैं
  • Zig भाषा छोटे WASM बाइनरी बनाने के लिए उपयुक्त है. लेकिन अगर आकार 100KB से कम हो, तो size कोई महत्वपूर्ण factor नहीं है.
  • built-in GC हर app के लिए महत्वपूर्ण नहीं है, और GC के बिना web app बनाना बेहतर है.
  • WASM का उपयोग करने वाले apps की सफलता का मुख्य कारण अब भी performance improvement है.
  • ClojureScript, TypeScript, ReasonML जैसी compile-to-JS भाषाओं के जरिए बहुत पहले से JS के अलावा अन्य भाषाओं में DOM programming की जाती रही है.
  • asm.js और emscripten के जरिए WASM से पहले भी C-आधारित भाषाओं को web पर compile करके उपयोग किया जाता था.
  • Google Maps और Google Earth, WASM का उपयोग करने वाले प्रमुख apps हैं.