Google Sheets, Google के उन शुरुआती प्रॉडक्ट में से एक है जो Chrome पर WasmGC का इस्तेमाल करता है. इस बदलाव का एलान 2022 में किया गया था. Sheets और Chrome की टीमों ने स्टैंडर्डाइज़ेशन, इंजीनियरिंग, और टूल के लिए साझेदारी की है, ताकि ऑप्टिमाइज़ेशन के बारे में रीयल-टाइम में सुझाव दिए जा सकें. इस साझेदारी से यह उदाहरण मिलता है कि Google की इंजीनियरिंग टीमें, Chrome के साथ मिलकर कैसे बेहतर तरीके से काम कर सकती हैं, ताकि ज़्यादा Google ऐप्लिकेशन WasmGC पर चल सकें.
चैलेंज: JavaScript
Google Sheets का कैलकुलेशन इंजन, मूल रूप से Java में लिखा गया था और इसे 2006 में लॉन्च किया गया था. प्रॉडक्ट के शुरुआती दिनों में, सभी गणना सर्वर पर की जाती थी. हालांकि, साल 2013 से यह इंजन, ब्राउज़र में JavaScript का इस्तेमाल करके चल रहा है. शुरुआत में, इसे Google Web Toolkit (GWT) की मदद से पूरा किया गया था. इसके बाद, Java to Closure JavaScript transpiler (J2CL) की मदद से पूरा किया गया. JavaScript कैलकुलेशन इंजन, वेब वर्कर्स में चलता है और MessageChannel का इस्तेमाल करके मुख्य थ्रेड से संपर्क करता है.
उपयोगकर्ताओं को कैलकुलेशन इंजन के सर्वर वर्शन से JavaScript वर्शन पर माइग्रेट करना एक बड़ी चुनौती थी. इसके बाद, उन्हें GWT से J2CL पर माइग्रेट करना भी एक बड़ी चुनौती थी. इसके लिए, पुष्टि करने की ज़रूरत थी. Sheets की टीम ने पुष्टि करने का एक इंटरनल तरीका विकसित किया है, ताकि यह पक्का किया जा सके कि JavaScript कैलकुलेशन इंजन, Java वर्शन के जैसे ही नतीजे दे. यह तरीका, शीट के बड़े कॉर्पस को प्रोसेस कर सकता है. साथ ही, यह पुष्टि कर सकता है कि कैलकुलेशन इंजन के कई वर्शन के नतीजे एक जैसे हैं या नहीं. Sheets की टीम, Sheets में किए गए बदलावों की पुष्टि करने के लिए, नियमित तौर पर इस टूल का इस्तेमाल करती है. हालांकि, टीम ने सिर्फ़ उन कैलकुलेशन के नतीजों की तुलना नहीं की, बल्कि क्लाइंट पर JavaScript और सर्वर पर Java के बीच परफ़ॉर्मेंस की तुलना भी की. उन्हें पता चला कि कैलकुलेशन इंजन का JavaScript वर्शन, Java वर्शन से तीन गुना धीमा था.
JavaScript, Java से धीमा क्यों है?
JavaScript, डाइनैमिक भाषा के लिए तेज़ है. पिछले 15 सालों में, Maglev, Sparkplug, और Turbofan जैसे जस्ट-इन-टाइम (जेआईटी) कंपाइलर पर ज़्यादा निवेश करने से, JavaScript की परफ़ॉर्मेंस बेहतर हुई है. हालांकि, JavaScript के लूज़ टाइप और डाइनैमिक व्यवहार की वजह से, JIT कंपाइलर के लिए सबसे अच्छा कोड जनरेट करना मुश्किल हो जाता है. इसका मतलब है कि रॉ थ्रूपुट के लिए, JavaScript अब भी Java और C++ जैसी भाषाओं से पीछे है. TypeScript, JavaScript में टाइप सेफ़्टी जोड़ता है. हालांकि, टाइप की जानकारी को डेवलपमेंट को आसान बनाने के लिए डिज़ाइन किया गया है, न कि बेहतर कोड जनरेट करने के लिए कंपाइलर को ज़रूरी गारंटी देने के लिए. Google Sheets जैसे मामलों में, बड़ी स्प्रेडशीट का हिसाब लगाने में 10 सेकंड लग सकते हैं. ऐसे में, JavaScript तेज़ है, लेकिन ज़रूरत के मुताबिक नहीं.
समस्या का हल: WasmGC
WasmGC, मौजूदा WebAssembly स्पेसिफ़िकेशन का एक्सटेंशन है. इसमें, ग़ैर-ज़रूरी डेटा इकट्ठा करने वाली भाषाओं (जैसे, Java) को कंपाइल करने के लिए ज़रूरी प्राइमिटिव जोड़े जाते हैं. उदाहरण के लिए, WasmGC, टाइप तय करने और इकट्ठा किए गए ग़ैर-ज़रूरी डेटा के स्ट्रक्चर को असाइन करने के लिए निर्देश जोड़ता है. WasmGC, गै़रबेज कलेक्शन वाली भाषाओं के लिए वही काम करेगा जो Wasm ने C++ (उदाहरण के लिए, Photoshop या Google Earth) के लिए किया था. इसका मकसद, उन्हें नेटिव स्पीड के करीब वेब पर लाना है. Google का मानना है कि गै़रबेज कलेक्शन वाली भाषाओं की लोकप्रियता की वजह से, WasmGC का असर Wasm से ज़्यादा हो सकता है.
Google Workspace, Chrome के साथ साझेदारी करता है
WasmGC एमवीपी ड्राफ़्ट स्पेसिफ़िकेशन को 2019 में पब्लिश किया गया था. साल 2020 के आखिर में, Google Workspace और Chrome ने Sheets के कैलकुलेशन इंजन का इस्तेमाल करके, WasmGC का आकलन करने के लिए साझेदारी की थी. Workspace की मल्टीप्लैटफ़ॉर्म टीम के पास कंपाइलर और ट्रांसपाइलर बनाने और उन्हें ऑप्टिमाइज़ करने की काफ़ी विशेषज्ञता है. Workspace का हिस्सा Sheets, WasmGC का आकलन करने के लिए सबसे सही विकल्प के तौर पर चुना गया था: यह परफ़ॉर्मेंस के हिसाब से संवेदनशील है. साथ ही, इसमें परफ़ॉर्मेंस को बेहतर बनाने और सही होने की पुष्टि करने के लिए बेहतर तरीके मौजूद हैं. Chrome में V8 टीम है, जो WasmGC रनटाइम को बनाने और ऑप्टिमाइज़ करने के साथ-साथ, पहले से ऑप्टिमाइज़ किए गए (एओटी) वर्शन बनाने के लिए, Binaryen में योगदान देती है. Chrome और Workspace में, WasmGC टूलचेन बनाने और उसे ऑप्टिमाइज़ करने के लिए ज़रूरी सभी विशेषज्ञता मौजूद है. साथ ही, Google Sheets को टेस्टबेड के तौर पर इस्तेमाल किया जा सकता है.
पहला प्रोटोटाइप
साल 2021 के मध्य तक, टीमों के पास Java से WasmGC कंपाइलर काम कर रहा था. उसी साल के आखिर तक, उनके पास Google Sheets का एक प्रोटोटाइप वर्शन था, जो WasmGC के तौर पर काम कर रहा था और कैलकुलेशन कर रहा था. इस दौरान, उन्हें कई चुनौतियों का सामना करना पड़ा. प्रोफ़ाइल बनाने और हीप डंप लेने के लिए टूल मौजूद नहीं थे. इसलिए, उन्हें बनाना पड़ा. मौजूदा लागू करने की सुविधा, कई JavaScript लाइब्रेरी पर निर्भर थी. इसके लिए, WasmGC के लिए बदलाव ढूंढने या लिखने पड़ते थे. Wasm कैलकुलेशन इंजन की सटीक जानकारी की पुष्टि करने में काफ़ी समय लगा. इसकी वजह यह है कि स्पेसिफ़िकेशन, कंपाइलर, और नई लाइब्रेरी प्रयोग के तौर पर उपलब्ध हैं. हालांकि, Sheets में पुष्टि करने के तरीके फिर से बहुत मददगार साबित हुए. आखिरकार, टीमों ने इसे काम कर लिया और 2022 की शुरुआत में परफ़ॉर्मेंस डेटा मिलना शुरू हो गया.
अन्य ऑप्टिमाइज़ेशन
Sheets Wasm के शुरुआती वर्शन में, कैलकुलेशन की परफ़ॉर्मेंस JavaScript के मुकाबले करीब दो गुना धीमी थी. हालांकि, नए स्पेसिफ़िकेशन, नए कंपाइलर, और कई नई लाइब्रेरी के लिए यह खराब नतीजा नहीं है. इसके बाद, Sheets की टीम ने ऑप्टिमाइज़ेशन शुरू किया. उन्हें मिले ऑप्टिमाइज़ेशन में, कुछ कैटगरी शामिल थीं:
- Java वर्चुअल मशीन (JVM) और V8 में पहले से मौजूद मुख्य ऑप्टिमाइज़ेशन को दोहराना.
- ज़्यादा ऑप्टिमाइज़ किए गए ब्राउज़र एपीआई का इस्तेमाल करना.
- JavaScript के हिसाब से कोडिंग पैटर्न हटाना.
सबसे पहले, Sheets की टीम को उन ऑप्टिमाइज़ेशन को दोहराना था जो पहले से ही अन्य टूलचेन में मौजूद हैं. इसका सबसे अच्छा उदाहरण, वर्चुअल मेथड डिस्पैचिंग को ऑप्टिमाइज़ करना है. इसे JVM और V8 ने लंबे समय से ऑप्टिमाइज़ किया है, लेकिन WasmGC के लिए ऐसा कुछ नहीं था. संदिग्ध इनलाइनिंग और डिवर्चुअलाइज़ेशन—दो बहुत ही सामान्य ऑप्टिमाइज़ेशन लागू करने से, Chrome में कैलकुलेशन का समय करीब 40% तक कम हो गया.
दूसरा, कुछ मामलों में ब्राउज़र एपीआई, ऑप्टिमाइज़ किए गए नेटिव तरीके से काम करते हैं. इनके मुकाबले, Wasm का इस्तेमाल करना मुश्किल होता है. स्ट्रिंग और रेगुलर एक्सप्रेशन, इसके दो अच्छे उदाहरण हैं. खास तौर पर, रेगुलर एक्सप्रेशन के लिए, टीम को Chrome में re2j (WasmGC में कंपाइल किया गया) से RegExp ब्राउज़र एपीआई पर स्विच करने पर, रेगुलर एक्सप्रेशन के ऑपरेशन की स्पीड में करीब 100 गुना की बढ़ोतरी दिखी. यह एपीआई, हर रेगुलर एक्सप्रेशन को अपने मशीन कोड में कंपाइल कर सकता है.
आखिर में, उन्हें पता चला कि सालों तक ऑप्टिमाइज़ करने की वजह से, कोडबेस को JavaScript के हिसाब से ज़्यादा फ़िट किया गया था. उदाहरण के लिए, उनके पास Sheets में एक मुख्य डेटा स्ट्रक्चर था, जो ऐरे और मैप के बीच की लाइनें धुंधला कर रहा था. यह JavaScript में बेहतर तरीके से काम करता है, जो स्पैर्स ऐरे को मैप के तौर पर अपने-आप मॉडल करता है. हालांकि, यह अन्य प्लैटफ़ॉर्म पर धीमा होता है. इसलिए, उन्हें कोड को फिर से लिखना पड़ा, ताकि वह किसी भी प्लैटफ़ॉर्म पर काम कर सके. टीम को WebAssembly में एक और बात पसंद है: इससे मल्टीप्लैटफ़ॉर्म ऐप्लिकेशन को वेब पर अच्छी परफ़ॉर्मेंस मिलती है. आपको अपने पूरे ऐप्लिकेशन को JavaScript की खास बातों के हिसाब से बनाने की ज़रूरत नहीं है.
आखिरी नतीजा
इन सभी ऑप्टिमाइज़ेशन के बाद, Sheets के WasmGC के फ़ाइनल वर्शन में कैलकुलेशन की परफ़ॉर्मेंस, JavaScript के मुकाबले करीब दो गुना ज़्यादा हो गई है. यह परफ़ॉर्मेंस, WasmGC के शुरुआती वर्शन की तुलना में चार गुना बेहतर है.
नतीजा
WasmGC एक बेहतरीन टेक्नोलॉजी है. इससे डेवलपर, वेब ऐप्लिकेशन बनाने के तरीके को बेहतर बना सकते हैं. Google को उम्मीद है कि आने वाले सालों में, WasmGC को शेयर की गई मेमोरी की मल्टीथ्रेडिंग के साथ काम करने के लिए बेहतर बनाया जाएगा. साथ ही, सिंगल थ्रेड की परफ़ॉर्मेंस को और बेहतर बनाया जाएगा. हमारा सुझाव है कि सभी वेब डेवलपर अपने अगले बेहतर परफ़ॉर्म करने वाले प्रोजेक्ट के लिए, WasmGC का इस्तेमाल करें. हमारे साथ जुड़ें और वेब को ज़्यादा तेज़ और आसान बनाएं!
आभार
WasmGC को लागू करने और इस केस स्टडी पर काम करने वाले लोगों का धन्यवाद: दिवास अधीकारी, मैथ्यू अल्ब्राइट, क्सेनिया बुकिना, जूलियन ड्रामाक्स, असिम फ़ज़ल, माइकल फ़्रेड्रिक, ग़ोक्तुग़ गोकडोगन, जैनिस गु, आदम क्लेन, मानोस कोकोटोस, जैकब कुम्मेरो, मैथियास लीडके, थॉमस लाइवली, रॉबर्टो ल्यूब्लिनरमन, विष्रुत मेहता, थॉमस नैटस्टैड, जोश पर्लस्टीन, जॉकीम पेरोटी, क्रिस रुनेस, स्टीवन सवानो, डेरेक शफ़, टिम सीअर्स, माइकल थॉमस, युआन तियान, फिलिप वीस, मेसन वू, अलोन ज़काई, और एमानुएल ज़िगलर.