🙆🏼 👲🏼 🤞🏻 हमने Yandex.Maps में WebAssembly को कैसे लागू किया और हमने जावास्क्रिप्ट क्यों छोड़ा 🔱 🚢 🚶🏿

मेरा नाम Valery Shavel है, मैं Yandex.Maps वेक्टर इंजन की विकास टीम से हूं। हाल ही में, हमने इंजन में WebAssembly तकनीक को लागू किया। नीचे मैं आपको बताऊंगा कि हमने इसे क्यों चुना, हमें क्या परिणाम मिले और आप अपने प्रोजेक्ट में इस तकनीक का उपयोग कैसे कर सकते हैं।

Yandex.Maps में, एक वेक्टर मानचित्र में टाइल नामक टुकड़े होते हैं। वास्तव में, टाइल नक्शे का अनुक्रमित क्षेत्र है। नक्शा वेक्टर है, इसलिए प्रत्येक टाइल में कई ज्यामितीय आदिम हैं। टाइलें सर्वर से क्लाइंट को एन्कोडेड आती हैं, और प्रदर्शित करने से पहले सभी प्राइमेटिक्स को संसाधित करना आवश्यक है। कभी-कभी इसमें काफी समय लगता है। एक टाइल में 2 हजार से अधिक पॉलीलाइन और बहुभुज हो सकते हैं।

जब आदिम प्रसंस्करण, प्रदर्शन सबसे महत्वपूर्ण है। यदि टाइल जल्दी से पर्याप्त रूप से तैयार नहीं की जाती है, तो उपयोगकर्ता इसे बहुत देर से देखेगा, और अगली टाइलें कतार में विलंबित होंगी। प्रसंस्करण को गति देने के लिए, हमने अपेक्षाकृत नई WebAssembly (Wasm) तकनीक का प्रयास करने का निर्णय लिया।

मैप्स में WebAssembly का उपयोग करना

अब प्राइमेटिक्स की अधिकांश प्रक्रिया पृष्ठभूमि थ्रेड (वेब वर्कर) में होती है, जो एक अलग जीवन जीती है। यह जितना संभव हो उतना मुख्य धागा को उतारने के लिए किया जाता है। इस प्रकार, जब कार्ड दिखाने का कोड सेवा पृष्ठ पर एम्बेडेड होता है, जो स्वयं एक महत्वपूर्ण भार जोड़ सकता है, तो कम ब्रेक होंगे। नकारात्मक पक्ष यह है कि आपको मुख्य थ्रेड और वेब वर्कर के बीच संदेश को ठीक से कॉन्फ़िगर करने की आवश्यकता है।

पृष्ठभूमि थ्रेड में होने वाली प्रोसेसिंग का हिस्सा अनिवार्य रूप से दो चरणों में होता है:

सर्वर से आने वाला प्रोटोबॉफ़ प्रारूप डिकोड किया जाता है ।
ज्यामिति उत्पन्न होती है और बफ़र्स को लिखी जाती है।

दूसरे चरण में, वेबजीएल के लिए वर्टेक्स और इंडेक्स बफ़र्स बनते हैं । इन बफ़र्स का उपयोग निम्नानुसार प्रतिपादन करते समय किया जाता है। एक वर्टेक्स बफर में प्रत्येक वर्टिक्स अपने मापदंडों के लिए होता है, जो एक विशेष क्षण में स्क्रीन पर इसकी स्थिति निर्धारित करने के लिए आवश्यक होते हैं। सूचकांक बफर में सूचकांकों के त्रिगुण होते हैं। प्रत्येक ट्रिपल का मतलब है कि संकेतित सूचकांकों में वर्टेक्स बफर से कोने के साथ एक त्रिकोण स्क्रीन पर प्रदर्शित किया जाना चाहिए। इसलिए, आदिम को त्रिकोण में विभाजित किया जाना चाहिए, जो समय लेने वाला कार्य भी हो सकता है:

जाहिर है, दूसरे चरण के दौरान, बहुत सारे मेमोरी हेरफेर और गणितीय गणनाएं होती हैं, क्योंकि आदिम के सही प्रतिपादन के लिए, आपको आदिम के प्रत्येक शीर्ष के बारे में बहुत अधिक जानकारी की आवश्यकता होती है:

हम अपने जावास्क्रिप्ट कोड के प्रदर्शन से खुश नहीं थे। इस समय, सभी ने WebAssembly के बारे में लिखना शुरू किया, प्रौद्योगिकी लगातार विकसित हो रही थी और सुधार कर रही थी। शोध को पढ़ने के बाद, हमने सुझाव दिया कि वासम हमारे परिचालन को गति दे सकता है। यद्यपि हम इस बारे में पूरी तरह से आश्वस्त नहीं थे: इतने बड़े प्रोजेक्ट में वास के उपयोग पर डेटा खोजना मुश्किल हो गया।

Wasm भी टाइपस्क्रिप्ट से कुछ बदतर है:

हमें उन कार्यों के साथ एक विशेष मॉड्यूल को इनिशियलाइज़ करना होगा जो हमें चाहिए। इस कार्यक्षमता के काम करने से पहले इसमें देरी हो सकती है।
वास का संकलन करते समय स्रोत कोड का आकार टीएस की तुलना में बहुत बड़ा है।
डेवलपर्स को कोड निष्पादन के एक वैकल्पिक संस्करण का समर्थन करना है, जो कि फ्रंटएंड के लिए एक atypical भाषा में भी लिखा गया है।

हालाँकि, इस सब के बावजूद, हमने अपने कोड का वसीम का उपयोग करके पुनर्लेखन का जोखिम उठाया।

WebAssembly सामान्य जानकारी

वासम एक द्विआधारी प्रारूप है; आप इसमें विभिन्न भाषाओं को संकलित कर सकते हैं, और फिर एक ब्राउज़र में कोड चला सकते हैं। अक्सर, ऐसे पूर्व-संकलित कोड क्लासिक जावास्क्रिप्ट की तुलना में तेज़ होते हैं। WebAssembly प्रारूप के कोड में पृष्ठ के DOM तत्वों तक पहुंच नहीं है और, एक नियम के रूप में, क्लाइंट पर समय लेने वाले कम्प्यूटेशनल कार्यों को करने के लिए उपयोग किया जाता है।

हमने C ++ को संकलित भाषा के रूप में चुना, क्योंकि यह काफी सुविधाजनक और तेज है।

WebAssembly में C ++ को संकलित करने के लिए, हमने emscripten का उपयोग किया। इसे स्थापित करने और C ++ प्रोजेक्ट में जोड़ने के बाद, मॉड्यूल प्राप्त करने के लिए, आपको मुख्य प्रोजेक्ट फ़ाइल को एक निश्चित तरीके से लिखना होगा। उदाहरण के लिए, यह इस तरह दिख सकता है:

#include <emscripten/bind.h> #include <emscripten.h> #include <math.h> struct Point { double x; double y; }; double sqr(double x) { return x * x; } EMSCRIPTEN_BINDINGS(my_value_example) { emscripten::value_object<Point>("Point") .field("x", &Point::x) .field("y", &Point::y) ; emscripten::register_vector<Point>("vector<Point>"); emscripten::function("distance", emscripten::optional_override( [](Point point1, Point point2) { return sqrt(sqr(point1.x - point2.x) + sqr(point1.y - point2.y)) ; })); }

इसके बाद, मैं वर्णन करूंगा कि आप अपने टाइपस्क्रिप्ट प्रोजेक्ट में इस कोड का उपयोग कैसे कर सकते हैं।

कोड में, हम पॉइंट स्ट्रक्चर को परिभाषित करते हैं और टाइपस्क्रिप्ट में प्वाइंट इंटरफेस में मैप करते हैं, जिसमें दो फील्ड होंगे - x और y, वे स्ट्रक्चर के फील्ड से मेल खाते हैं।

इसके अलावा, यदि हम C ++ से टाइपस्क्रिप्ट के लिए मानक वेक्टर कंटेनर वापस करना चाहते हैं, तो हमें इसे प्वाइंट प्रकार के लिए पंजीकृत करना होगा। फिर टाइपस्क्रिप्ट में आवश्यक कार्यों के साथ इंटरफ़ेस इसके अनुरूप होगा।

और अंत में, कोड दिखाता है कि टाइप फ़ंक्शन से इसे इसी नाम से कॉल करने के लिए अपने फ़ंक्शन को कैसे पंजीकृत किया जाए।

Emscripten का उपयोग करके फ़ाइल संकलित करें और परिणामी मॉड्यूल को अपने टाइपस्क्रिप्ट प्रोजेक्ट में जोड़ें। अब हम एक मनमाने emscripten मॉड्यूल के लिए जेनेरिक d.ts फ़ाइल लिख सकते हैं, जिसमें उपयोगी कार्य और प्रकार पूर्वनिर्धारित हैं:

 declare module "emscripten_module" { interface EmscriptenModule { readonly wasmMemory: WebAssembly.Memory; readonly HEAPU8: Uint8Array; readonly HEAPF64: Float64Array; locateFile: (path: string) => string; onRuntimeInitialized: () => void; _malloc: (size: size_t) => uintptr_t; _free: (addr: size_t) => uintptr_t; } export default EmscriptenModule; export type uintptr_t = number; export type size_t = number; }

और हम अपने मॉड्यूल के लिए d.ts फ़ाइल लिख सकते हैं:

 declare module "emscripten_point" { import EmscriptenModule, {uintptr_t, size_t} from 'emscripten_module'; interface NativeObject { delete: () => void; } interface Vector<T> extends NativeObject { get(index: number): T; size(): number; } interface Point { readonly x: number; readonly y: number; } interface PointModule extends EmscriptenModule { distance: (point1: Point, point2: Point) => number; } type PointModuleUninitialized = Partial<PointModule>; export default function createModuleApi(Module: Partial<PointModule>): PointModule; }

अब हम एक फ़ंक्शन लिख सकते हैं जो मॉड्यूल इनिशियलाइज़ेशन के लिए वादा करेगा, और इसका उपयोग करेगा:

 import EmscriptenModule from 'emscripten_module'; import createPointModuleApi, {PointModule} from 'emscripten_point'; import * as pointModule from 'emscripten_point.wasm'; /** * Promisifies initialization of emscripten module. * * @param moduleUrl URL to wasm file, it could be encoded data URL. * @param moduleInitializer Escripten module factory, * see https://emscripten.org/docs/compiling/WebAssembly.html#compiler-output. */ export default function initEmscriptenModule<ModuleT extends EmscriptenModule>( moduleUrl: string, moduleInitializer: (module: Partial<EmscriptenModule>) => ModuleT ): Promise<ModuleT> { return new Promise((resolve) => { const module = moduleInitializer({ locateFile: () => moduleUrl, onRuntimeInitialized: function (): void { // module itself is thenable, to prevent infinite promise resolution delete (<any>module).then; resolve(module); } }); }); } const initialization = initEmscriptenModule( 'data:application/wasm;base64,' + pointModule, createPointModuleApi );

अब इस प्रॉमिस के लिए हमें डिस्टेंस फंक्शन के साथ-साथ हमारा मॉड्यूल मिलता है।

दुर्भाग्य से, आप ब्राउज़र में लाइन द्वारा वॉसम कोड लाइन को डीबग नहीं कर सकते हैं। इसलिए, सामान्य सी ++ की तरह उन पर परीक्षण लिखना और कोड चलाना आवश्यक है, फिर आपके पास सुविधाजनक डिबगिंग का अवसर होगा। फिर भी, ब्राउज़र में भी, आपके पास मानक कॉउट स्ट्रीम तक पहुंच है, जो ब्राउज़र कंसोल में सब कुछ आउटपुट करेगा।

इस लिंक के माध्यम से लेख का एक प्रोजेक्ट उदाहरण उपलब्ध है, जहाँ आप webpack.config और CMakeLists की सेटिंग्स देख सकते हैं।

परिणाम

इसलिए, हमने अपने कोड के कुछ हिस्सों को फिर से लिखा और पॉलीगॉन और पॉलीगॉन पर विचार करने के लिए एक प्रयोग शुरू किया। चित्र आरेख और जावास्क्रिप्ट के लिए एक टाइल के लिए औसत परिणाम दिखाता है:

नतीजतन, हमें प्रत्येक मीट्रिक के लिए ऐसे रिश्तेदार गुणांक मिले:

जैसा कि आप शुद्ध आदिम पार्सिंग समय और टाइल डिकोडिंग समय से देख सकते हैं, वासम चार गुना से अधिक तेज है। यदि आप कुल पार्सिंग समय को देखते हैं, तो अंतर भी महत्वपूर्ण है, लेकिन यह अभी भी कम है। ऐसा वास के लिए डेटा स्थानांतरित करने और परिणाम एकत्र करने की लागत के कारण है। यह भी ध्यान देने योग्य है कि पहली टाइल में समग्र लाभ बहुत अधिक है (पहले दस में - पांच बार से अधिक)। हालांकि, फिर सापेक्ष गुणांक लगभग तीन तक कम हो जाता है।

नतीजतन, यह सब मिलकर पृष्ठभूमि थ्रेड में एक टाइल के प्रसंस्करण समय को 20-25% तक कम करने में मदद करता है। बेशक, यह अंतर पिछले वाले की तरह महान नहीं है, लेकिन आपको यह समझने की जरूरत है कि टूटी हुई लाइनें और पॉलीगॉन पार्स करना सभी टाइल प्रसंस्करण से दूर है।

अगर हम मॉड्यूल को शुरू करने की आवश्यकता के बारे में बात करते हैं, तो इसकी वजह से, लगभग आधे उपयोगकर्ताओं को पहले टाइल को पार्स करने से पहले देरी हुई। मंझला विलंब 188 एमएस है। देरी केवल पहली टाइल से पहले होती है, और पार्सिंग में जीत स्थिर होती है, इसलिए आप शुरुआत में एक छोटे से ठहराव के साथ रख सकते हैं और इसे एक गंभीर समस्या नहीं मानते हैं।

एक अन्य नकारात्मक पक्ष स्रोत कोड फ़ाइल का आकार है। वसीम के बिना पूरे वेक्टर मैप इंजन के लिए गज़िप-संपीड़ित मिनिफ़ाइड कोड - वास - 191 KB के साथ। उसी समय, केवल टूटी हुई रेखाओं और आयतों के पार्सिंग को वस्म में लागू किया जाता है, न कि सभी प्राइमेटिव्स जो एक टाइल में हो सकते हैं। इसके अलावा, प्रोटोबुफ़ को डीकोड करने के लिए, मुझे शुद्ध C में एक पुस्तकालय कार्यान्वयन का चयन करना था, C ++ कार्यान्वयन के साथ आकार और भी बड़ा था। C ++ का संकलन करते समय -O3 के बजाय -Oz संकलक ध्वज का उपयोग करके इस अंतर को कुछ हद तक कम किया जा सकता है, लेकिन यह अभी भी महत्वपूर्ण है। इसके अलावा, इस तरह के प्रतिस्थापन के साथ, हम उत्पादकता खो देते हैं।

फिर भी, स्रोत के आकार ने कार्ड के आरंभीकरण की गति को महत्वपूर्ण रूप से प्रभावित नहीं किया। वासम केवल धीमे उपकरणों पर खराब है, और अंतर 2% से कम है। वासेम के साथ कार्यान्वयन में वेक्टर टाइल्स का प्रारंभिक दृश्यमान सेट, जेएस कार्यान्वयन के मुकाबले उपयोगकर्ताओं को थोड़ा तेज दिखाया गया था। यह पहली संसाधित टाइलों पर अधिक लाभ के कारण है, जबकि जेएस अभी तक अनुकूलित नहीं है।

इस प्रकार, अगर आप जावास्क्रिप्ट कोड प्रदर्शन के साथ सहज नहीं हैं, तो वासम अब एक योग्य विकल्प है। उसी समय, आप हमसे कम प्रदर्शन प्राप्त कर सकते हैं, या आप इसे बिल्कुल नहीं प्राप्त कर सकते हैं। यह इस तथ्य के कारण है कि कभी-कभी जावास्क्रिप्ट स्वयं बहुत तेज़ी से काम करता है, और वास में आपको डेटा स्थानांतरित करने और परिणाम इकट्ठा करने की आवश्यकता होती है।

हमारे नक्शे अब नियमित जावास्क्रिप्ट चलाते हैं। यह इस तथ्य के कारण है कि पार्सिंग में लाभ सामान्य पृष्ठभूमि के खिलाफ इतना महान नहीं है, और इस तथ्य के कारण कि केवल कुछ प्रकार के प्राइमेटिव्स को वास में लागू किया जाता है। यदि यह बदल जाता है, तो शायद हम Wasm का उपयोग करेंगे। इसके खिलाफ एक और शक्तिशाली तर्क विधानसभा और डिबगिंग की जटिलता है: दो भाषाओं में एक परियोजना का समर्थन केवल तभी समझ में आता है जब प्रदर्शन लाभ के लायक होता है।

हमने Yandex.Maps में WebAssembly को कैसे लागू किया और हमने जावास्क्रिप्ट क्यों छोड़ा

मैप्स में WebAssembly का उपयोग करना

WebAssembly सामान्य जानकारी

परिणाम

More articles: