अपने JIT को जानें: कार के करीब

हमारे द्वारा लिखे गए कोड को निष्पादित करने से पहले, यह एक लंबा रास्ता तय करता है। आरआईटी ++ 2018 पर अपनी रिपोर्ट में एंड्रे मेलिखोव ने वी 8 इंजन के उदाहरण का उपयोग करते हुए इस रास्ते पर हर कदम की जांच की। यह पता लगाने के लिए बिल्ली के नीचे आओ कि हमें कंपाइलर के सिद्धांतों की गहरी समझ और जावास्क्रिप्ट कोड को और अधिक उत्पादक कैसे बनाया जाए।



हमें पता चलेगा कि क्या WASM कोड प्रदर्शन में सुधार के लिए एक चांदी की गोली है, और क्या अनुकूलन हमेशा उचित हैं।

स्पोइलर: "प्रीमेच्योर ऑप्टिमाइज़ेशन सभी बीमारियों की जड़ है," डोनाल्ड नुथ।



वक्ता के बारे में: आंद्रेई मेलिखोव Yandex.Money में काम करता है, Node.js पर सक्रिय रूप से लिखता है, और ब्राउज़र में कम है, इसलिए सर्वर जावास्क्रिप्ट उसके करीब है। एंड्रयू देवशात समुदाय का समर्थन और विकास करता है, इसलिए GitHub या माध्यम की जाँच करें।

प्रेरणा और शब्दावली

आज हम JIT संकलन के बारे में बात करेंगे। मुझे लगता है कि यह आपके लिए दिलचस्प है, क्योंकि आप इसे पढ़ रहे हैं। हालांकि, आइए स्पष्ट करें कि आपको यह जानने की आवश्यकता है कि जेआईटी क्या है और वी 8 कैसे काम करता है, और एक ब्राउज़र में रिएक्ट लिखना पर्याप्त क्यों नहीं है।

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

विकिपीडिया का कहना है कि जावास्क्रिप्ट एक उच्च स्तरीय व्याख्यात्मक प्रोग्रामिंग भाषा है जिसमें गतिशील टाइपिंग है। हम इन शर्तों से निपटेंगे।

संकलन और व्याख्या

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

व्याख्या - जब हम कोड वितरित करते हैं तो यह होता है।

जावास्क्रिप्ट के रूप में दिया जाता है - यह एक व्याख्या की गई भाषा है, जैसा कि विकिपीडिया पर लिखा गया है।

गतिशील और स्थिर टाइपिंग

स्थिर और गतिशील टाइपिंग अक्सर कमजोर और मजबूत टाइपिंग के साथ भ्रमित होती है। उदाहरण के लिए, C स्थिर कमजोर टाइपिंग वाली भाषा है। जावास्क्रिप्ट में कमजोर गतिशील टाइपिंग है।

कौन सा बेहतर है? यदि कार्यक्रम संकलित करता है, तो इसे उस पर्यावरण की ओर गियर किया जाता है जिसमें इसे निष्पादित किया जाएगा, जिसका अर्थ है कि यह बेहतर काम करेगा। स्टेटिक टाइपिंग इस कोड को अधिक कुशल बनाता है। जावास्क्रिप्ट में, विपरीत सच है।

लेकिन एक ही समय में, हमारा एप्लिकेशन अधिक जटिल होता जा रहा है: क्लाइंट और सर्वर दोनों पर, Node.js पर विशाल क्लस्टर दिखाई देते हैं, जो ठीक काम करते हैं और जावा अनुप्रयोगों को बदलने के लिए आते हैं।

लेकिन यह सब कैसे काम करता है अगर यह शुरू में एक हारे हुए लगता है।

JIT सबको समेट देगी! या कम से कम कोशिश करें।

हमारे पास एक जेआईटी (जस्ट इन टाइम संकलन) है जो रनटाइम पर होता है। हम उसके बारे में बात करेंगे।

जेएस इंजन

• अनलॉक्ड चक्र, जो इंटरनेट एक्सप्लोरर में स्थित है। यह जावास्क्रिप्ट के साथ भी काम नहीं करता है, लेकिन Jscript के साथ - ऐसा एक सबसेट है।
  
• आधुनिक चक्र और चक्र जो एज में काम करते हैं;
  
• फ़ायरफ़ॉक्स में स्पाइडरमोंकी;
• WebKit में JavaScriptCore। इसका उपयोग React Native में भी किया जाता है। यदि आपके पास Android के लिए RN अनुप्रयोग है, तो यह JavaScriptCore पर भी चलता है - इंजन अनुप्रयोग के साथ बंडल हो जाता है।
  
• V8 मेरा पसंदीदा है। यह सबसे अच्छा नहीं है, मैं सिर्फ Node.js के साथ काम करता हूं, जिसमें यह मुख्य इंजन है, जैसा कि सभी क्रोम आधारित ब्राउज़रों में है।
  
• राइनो और नैशोर्न जावा में उपयोग किए जाने वाले इंजन हैं। उनकी मदद से, आप वहां जावास्क्रिप्ट भी निष्पादित कर सकते हैं।
  
• जेरीस्क्रिप्ट - एम्बेडेड उपकरणों के लिए;
  
• और अन्य ...

आप अपना खुद का इंजन लिख सकते हैं, लेकिन यदि आप प्रभावी निष्पादन की ओर बढ़ते हैं, तो आप लगभग उसी योजना पर आएंगे, जिसे मैं बाद में दिखाऊंगा।

आज हम V8 के बारे में बात करेंगे, और हाँ, यह 8-सिलेंडर इंजन के नाम पर है।

हम हुड के नीचे चढ़ते हैं

जावास्क्रिप्ट को कैसे निष्पादित किया जाता है?

• जावास्क्रिप्ट में कोड लिखा है, जो आपूर्ति किया गया है।
  
• वह पार्स कर रहा है;
• निष्पादित किया जा रहा है;
• परिणाम प्राप्त होता है।
  

पार्सिंग एक सार सिंटैक्स ट्री में कोड को बदल देता है। एएसटी एक पेड़ के रूप में कोड की वाक्यात्मक संरचना का प्रदर्शन है। यह वास्तव में कार्यक्रम के लिए सुविधाजनक है, हालांकि इसे पढ़ना मुश्किल है।


एक पेड़ के रूप में सूचकांक 1 के साथ एक सरणी तत्व प्राप्त करना एक ऑपरेटर और दो ऑपरेंड के रूप में दर्शाया गया है: कुंजी और इन कुंजियों द्वारा संपत्ति को लोड करें।

एएसटी का उपयोग कहां किया जाता है?

एएसटी केवल इंजनों में नहीं है। एएसटी का उपयोग करते हुए, कई उपयोगिताओं एक्सटेंशन लिखते हैं, जिनमें शामिल हैं:

• ESLint;
• कोलाहल;
• खूबसूरत;
• Jscodeshift।

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



हम आगे बढ़ते हैं। प्रोसेसर सार सिंटैक्स ट्री को नहीं समझता है, इसे मशीन कोड की आवश्यकता है। इसलिए, दुभाषिया के माध्यम से आगे परिवर्तन होता है, क्योंकि भाषा की व्याख्या की जाती है।


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

JIT कम्पाइलर का अनुकूलन

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

इस तरह के अनुकूलन को सट्टा कहा जाता है , क्योंकि यह पहले कोड के साथ क्या हुआ है के ज्ञान पर अनुमान लगाता है। यही है, यदि संख्या प्रकार के साथ कुछ को 10 बार कहा जाता था, तो कंपाइलर सोचता है कि यह हर समय होगा और इस प्रकार के लिए अनुकूलन करता है।

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

const foo=(a, b) => a + b;
foo (1, 2);
foo (2, 3);

एक बार तह, दूसरी बार। संकलक भविष्यवाणी बनाता है: "ये संख्याएं हैं, मेरे पास संख्याओं को जोड़ने के लिए एक अच्छा समाधान है!" और आप foo('WTF', 'JS') लिखते हैं, और फ़ंक्शन को लाइनें पास करते हैं - हमारे पास जावास्क्रिप्ट है, हम एक संख्या के साथ एक पंक्ति जोड़ सकते हैं।

इस बिंदु पर, deoptimization होता है।



इसलिए, दुभाषिया को कंपाइलर द्वारा बदल दिया गया था। ऊपर दिए गए आरेख में एक बहुत ही सरल पाइपलाइन है। वास्तव में, सब कुछ थोड़ा अलग है।



जो पिछले साल तक था। पिछले साल, आप Google से बहुत सारी रिपोर्ट सुन सकते हैं कि उन्होंने टर्बोफैन के साथ एक नई पाइपलाइन लॉन्च की है और अब यह योजना सरल है।



दिलचस्प है, एक दुभाषिया यहाँ दिखाई दिया।



एक सार वाक्यविन्यास पेड़ को बायटेकोड में बदलने के लिए, और एक कंपाइलर के लिए बायटेकोड को पारित करने के लिए एक दुभाषिया की आवश्यकता होती है। डीओपिटिमाइजेशन के मामले में, वह फिर से दुभाषिया के पास जाता है।

दुभाषिया प्रज्वलन

पहले, इग्निशन दुभाषिया स्कीमा नहीं था। Google ने शुरू में कहा कि एक दुभाषिया की आवश्यकता नहीं है - जावास्क्रिप्ट पहले से ही कॉम्पैक्ट और व्याख्यात्मक है - हम कुछ भी नहीं जीत सकते।

लेकिन मोबाइल अनुप्रयोगों के साथ काम करने वाली टीम निम्नलिखित समस्या में भाग गई।



2013-2014 में, लोगों ने डेस्कटॉप की तुलना में इंटरनेट का उपयोग करने के लिए मोबाइल उपकरणों का उपयोग करना शुरू किया। मूल रूप से, यह एक iPhone नहीं है, लेकिन सरल उपकरणों से - उनके पास छोटी मेमोरी और एक कमजोर प्रोसेसर है।



इंटरप्रेटर शुरू करने से पहले 1 एमबी कोड के प्रारंभिक विश्लेषण का एक ग्राफ ऊपर है। यह देखा जा सकता है कि डेस्कटॉप बहुत जीतता है। IPhone भी खराब नहीं है, लेकिन इसमें एक अलग इंजन है, और हम V8 के बारे में बात कर रहे हैं, जो क्रोम में काम करता है।

क्या आप जानते हैं कि यदि आप iPhone पर Chrome इंस्टॉल करते हैं, तो यह अभी भी JavaScriptCore पर काम करेगा?

इस प्रकार, समय बर्बाद होता है - और यह केवल विश्लेषण है, निष्पादन नहीं - आपकी फ़ाइल लोड हो गई है, और यह समझने की कोशिश कर रहा है कि इसमें क्या लिखा गया है।


जब डेप्टिमाइजेशन होता है, तो आपको स्रोत कोड को फिर से लेने की आवश्यकता होती है, अर्थात। इसे कहीं संग्रहीत करने की आवश्यकता है। बहुत याद आई।

इस प्रकार, दुभाषिया के दो कार्य थे:

1. पार्सिंग ओवरहेड को कम करना;
   
2. मेमोरी की खपत कम करें।
   

कार्य एक बाइटेकोड दुभाषिया पर स्विच करके हल किए गए थे।


क्रोम में बाइटकोड एक बैटरी के साथ एक रजिस्टर मशीन है । स्पाइडरमोंकी के पास एक स्टैक्ड मशीन है, स्टैक पर सभी डेटा हैं, लेकिन कोई रजिस्टर नहीं है। यहाँ वे हैं।

हम पूरी तरह से विश्लेषण नहीं करेंगे कि यह कैसे काम करता है, बस कोड के टुकड़े को देखें।



यह यहाँ कहता है: मान जो बैटरी में निहित है और इसे मान में जोड़ें जो कि a0 रजिस्टर में है, जो कि वैरिएबल a में है । यहां अभी तक कुछ भी नहीं पता है। यदि यह वास्तविक कोडांतरक कोड था, तो यह इस बात की समझ के साथ लिखा जाएगा कि मेमोरी में किस तरह के बदलाव हैं, इसमें क्या है। यहां सिर्फ एक निर्देश है - रजिस्टर a0 में जो निहित है उसे लें और इसे उस मूल्य में जोड़ें जो बैटरी में निहित है।

बेशक, दुभाषिया केवल सार सिंटैक्स पेड़ को नहीं लेता है और इसे बायटेकोड में अनुवाद करता है।


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

अनुकूलन और विकृति

ठंडा और गर्म सुविधाएँ

यह सबसे आसान विषय है।

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



काम की योजना।

• इग्निशन (दुभाषिया) जानकारी एकत्र करता है। वह न केवल जावास्क्रिप्ट को बाइटकोड में परिवर्तित करता है, बल्कि यह भी समझता है कि किस प्रकार में आया, क्या कार्य गर्म हो गए, और वह संकलक को इस सब के बारे में बताता है।
• एक अनुकूलन है।
• संकलक कोड निष्पादित करता है। सब कुछ अच्छा काम करता है, लेकिन यहां एक प्रकार आता है कि वह उम्मीद नहीं करता था, उसके पास इस प्रकार के साथ काम करने के लिए कोड नहीं है।
• Deoptimization होता है। संकलक इस कोड के लिए इग्निशन दुभाषिया का उपयोग करता है।

यह एक सामान्य चक्र है जो हर समय होता है, लेकिन यह अनंत नहीं है। कुछ बिंदु पर, इंजन कहता है, "नहीं, अनुकूलन करना असंभव है," और अनुकूलन के बिना निष्पादित करना शुरू होता है। यह समझना महत्वपूर्ण है कि मोनोमोर्फिज्म का अवलोकन किया जाना चाहिए।

मोनोमोर्फिज्म तब होता है जब उसी प्रकार हमेशा आपके फ़ंक्शन के इनपुट पर आते हैं। यही है, अगर आपको हर समय स्ट्रिंग मिलती है, तो आपको वहां बूलियन पास करने की आवश्यकता नहीं है।

लेकिन वस्तुओं के साथ क्या करना है? वस्तुएं सभी वस्तु हैं। हमारे पास कक्षाएं हैं, लेकिन वे वास्तविक नहीं हैं - यह प्रोटोटाइप मॉडल पर सिर्फ चीनी है। लेकिन इंजन के अंदर तथाकथित छिपे हुए वर्ग हैं।

छिपी हुई कक्षाएं

वी 8 में ही नहीं, सभी इंजनों में छिपे हुए वर्ग हैं। हर जगह उन्हें अलग-अलग कहा जाता है, वी 8 के संदर्भ में यह मानचित्र है।

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

मानचित्र वस्तुओं की संरचना का वर्णन करता है, क्योंकि सिद्धांत रूप में, जावास्क्रिप्ट में, टाइपिंग केवल संरचनात्मक है, नाममात्र नहीं। हम यह बता सकते हैं कि हमारी वस्तु कैसी दिखती है, यह किस लिए जाती है।

छिपी हुई कक्षाओं की वस्तुओं के गुणों को हटाने / जोड़ने पर, ऑब्जेक्ट बदल जाता है, एक नया असाइन किया जाता है। कोड को देखते हैं।


हमारे पास एक निर्माता है जो टाइप प्वाइंट की एक नई वस्तु बनाता है।

• कोई वस्तु बनाएँ।
• एक छिपे हुए वर्ग को इसके साथ बाँधें, जो कहता है कि यह एक प्रकार की वस्तु है।
• हमने x फ़ील्ड को जोड़ा - एक नया छिपा हुआ वर्ग जो कहता है कि यह एक प्रकार की वस्तु है, जिसमें x मान पहले आता है।
• जोड़ा गया y - नए छिपे हुए वर्गों, जिसमें x, और फिर y।
• दूसरी वस्तु बनाई - वही काम होता है। यही है, वह वह भी बांधता है जो पहले से ही बनाया गया है। इस समय, ये दोनों वस्तुएं एक ही प्रकार (हिडन क्लासेस के माध्यम से) की हैं।
• जब कोई नया फ़ील्ड दूसरी ऑब्जेक्ट में जोड़ा जाता है, तो ऑब्जेक्ट में एक नया हिडन क्लासेस दिखाई देता है। अब इंजन p1 और P2 के लिए, ये विभिन्न वर्गों की वस्तुएं हैं, क्योंकि उनके पास अलग-अलग संरचनाएं हैं
• यदि आप पहली वस्तु को कहीं स्थानांतरित करते हैं, तो जब आप दूसरे को वहां स्थानांतरित करते हैं, तो डीओपिटिमाइजेशन होगा। पहला एक छिपे हुए वर्ग को संदर्भित करता है, दूसरा दूसरे को।

मैं छिपी हुई कक्षाओं की जांच कैसे कर सकता हूं?

Node.js में, आप नोड-नेटिव-सिंटैक्स चला सकते हैं। तब आपको एक विशेष वाक्यविन्यास में कमांड लिखने का अवसर मिलेगा, जो निश्चित रूप से उत्पादन में उपयोग नहीं किया जा सकता है। यह इस तरह दिखता है:

 %HaveSameMap({'a':1}, {'b':1}) 

कोई भी गारंटी नहीं देता है कि कल ये कमांड काम करेंगे, वे ECMAScript विनिर्देश में नहीं हैं, यह सभी डिबगिंग के लिए है।

आपको क्या लगता है कि दो वस्तुओं के लिए% HaveSameMap फ़ंक्शन को कॉल करने का परिणाम होगा। सही उत्तर गलत है, क्योंकि एक के पास एक क्षेत्र है, और दूसरे के पास बी है । ये अलग-अलग वस्तुएं हैं। इस ज्ञान का उपयोग इनलाइन कैश तकनीक के लिए किया जा सकता है।

इनलाइन कैश

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


इस स्थिति में, ऑब्जेक्ट में मानचित्र का एक लिंक होता है, जो कहता है: फ़ील्ड x प्राप्त करने के लिए, आपको एक ऑफसेट करना होगा, और हमें x प्राप्त करना होगा। आपको कहीं भी चढ़ना नहीं है, किसी भी प्रोटोटाइप में, सब कुछ पास है। इनलाइन कैश इसका उपयोग करता है।

• यदि हम पहली बार फ़ंक्शन को कॉल करते हैं, तो सब कुछ ठीक है, दुभाषिया ने अनुकूलन किया है
• दूसरी कॉल के लिए, एक मोनोमोर्फिक राज्य को बचाया जाता है।
• मैं फ़ंक्शन को तीसरी बार कहता हूं, थोड़ा अलग ऑब्जेक्ट {x: 3, y: 1} पास करें। Deoptimization होता है, यदि प्रकट होता है, तो हम एक बहुरूपी अवस्था में चले जाते हैं। अब इस फ़ंक्शन को निष्पादित करने वाला कोड जानता है कि दो अलग-अलग प्रकार की वस्तुएं इसमें उड़ सकती हैं।
• यदि हम कई बार अलग-अलग वस्तुओं को पास करते हैं, तो यह एक बहुरूपी अवस्था में रहता है, जिससे नए इफ़े जुड़ते हैं। लेकिन कुछ बिंदु पर आत्मसमर्पण करता है और एक मेगामॉर्फिक राज्य में चला जाता है, अर्थात्। जब: "बहुत सारे विभिन्न प्रकार प्रवेश द्वार पर आते हैं - मुझे नहीं पता कि इसे कैसे अनुकूलित किया जाए!"

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

सरणियों

जावास्क्रिप्ट में, विशिष्ट टाइप एरे के अलावा, एक प्रकार है
सरणी। V8 इंजन में उनमें से 6 हैं:

1. [1, 2, 3, 4] // PACKED_SMI_ELEMENTS - छोटे पूर्णांक का केवल एक पैक सरणी। उसके लिए अनुकूलन हैं।

2. [1.2, 2.3, 3.4, 4.6] // PACKED_DOUBLE_ELEMENTS - दोहरे तत्वों का एक पैक सरणी, इसके लिए अनुकूलन भी हैं, लेकिन धीमे हैं।

3. [1, 2, 3, 4, 'X'] // PACKED_ELEMENTS - एक पैक्ड सरणी जिसमें वस्तुएं, तार और बाकी सब कुछ होता है। उसके लिए भी, अनुकूलन हैं।

निम्नलिखित तीन प्रकार पहले तीन के रूप में एक ही प्रकार के सरणियाँ हैं, लेकिन छेद के साथ:

4. [1, / * छेद * /, 2, / * छेद * / /, 3, 4] // HOLEY_SMI सामग्री

5. (1.2, / * छेद * /, 2, / * छेद * /, 3,4] // HOLEY_DOUBLE / वेल्डिंग

6. [1, / * छेद * /, 'X'] // HOLEY_ELEMENTS

जब आपके सरणियों में छेद दिखाई देते हैं, तो अनुकूलन कम कुशल हो जाते हैं। वे खराब काम करना शुरू कर देते हैं, क्योंकि पुनरावृत्तियों के माध्यम से छंटनी इस पंक्ति के माध्यम से जाना असंभव है। प्रत्येक बाद का प्रकार कम अनुकूलित है



आरेख में, ऊपर की सब कुछ तेजी से अनुकूलित है। यही है, आपके सभी मूल तरीकों - मानचित्र, कम, सॉर्ट - अंदर अच्छी तरह से अनुकूलित हैं। लेकिन प्रत्येक प्रकार के साथ, अनुकूलन खराब हो जाता है।

उदाहरण के लिए, एक साधारण सरणी [ 1 , 2 , 3 ] इनपुट के लिए आया था (प्रकार - छोटे पूर्णांक पैक)। हमने इस सरणी को थोड़ा जोड़कर इसे बदल दिया - PACKED_DOUBLE_ELEMENTS स्थिति में चला गया। इसमें एक ऑब्जेक्ट जोड़ें - अगले राज्य पर जाएं, हरे रंग की आयत PACKED_ELEMENTS। इसमें छेद जोड़ें - HOLEY_ELEMENTS स्थिति पर जाएं। हम इसे अपनी पिछली स्थिति में पुनर्स्थापित करना चाहते हैं ताकि यह फिर से "अच्छा" बन जाए - हम जो कुछ भी लिखते हैं उसे हटा देते हैं और उसी अवस्था में रहते हैं ... छेद के साथ! यही है, आरेख के निचले दाहिने हिस्से में HOLEY_ELEMENTS। वापस यह काम नहीं करता है। आपकी सरणियाँ केवल बदतर हो सकती हैं, लेकिन इसके विपरीत नहीं।

सरणी जैसी वस्तु

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


हमारे दो पसंदीदा ऐरे-लाइक ऑब्जेक्ट्स तर्क और दस्तावेज हैं ।querySelectorAII। ऐसी सुंदर कार्यात्मक चीजें हैं।


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

क्या करने की जरूरत है?

• पुराने स्कूल के विकल्प - slice.call के माध्यम से () एक वास्तविक सरणी में बदल जाते हैं।
• आधुनिक विकल्प और भी बेहतर है: लिखना (... बाकी), एक साफ सरणी प्राप्त करें - तर्क नहीं - सब कुछ ठीक है!

QuerySelectorAll के साथ एक ही बात - प्रसार के कारण हम इसे एक पूर्ण सरणी में बदल सकते हैं और अन्य अनुकूलन के साथ काम कर सकते हैं।

बड़े ऐरे

पहेली: नया ऐरे (1000) बनाम सरणी = []
कौन सा विकल्प बेहतर है: तुरंत एक बड़ा सरणी बनाएं और इसे एक लूप में 1000 ऑब्जेक्ट्स के साथ भरें, या एक खाली बनाएं और इसे धीरे-धीरे भरें?

सही उत्तर: पर निर्भर करता है।

अंतर क्या है?

• जब हम पहले तरीके से एक सरणी बनाते हैं और 1000 तत्वों को भरते हैं, तो हम 1000 छेद बनाते हैं। यह सरणी अनुकूलित नहीं होगी। लेकिन वह जल्दी से लिखेंगे।
  
• दूसरे संस्करण के अनुसार एक सरणी बनाना, थोड़ी मेमोरी आवंटित की जाती है, हम लिखते हैं, उदाहरण के लिए, 60 तत्व, थोड़ी अधिक मेमोरी आवंटित की जाती है, आदि।

यही है, पहले मामले में हम जल्दी से लिखते हैं - हम धीरे-धीरे काम करते हैं; दूसरे में हम धीरे-धीरे लिखते हैं - हम जल्दी से काम करते हैं।

कचरा इकट्ठा करने वाला

कचरा उठाने वाला भी थोड़ा समय और संसाधन खाता है। गहराई से गोता लगाए बिना, मैं सबसे आम आधार दूंगा।



हमारे जेनेरेटिव मॉडल में युवा और पुरानी वस्तुओं का स्थान है । निर्मित वस्तु युवा वस्तुओं के अंतरिक्ष में गिरती है। कुछ समय बाद, सफाई शुरू होती है। यदि ऑब्जेक्ट को रूट से लिंक तक नहीं पहुँचा जा सकता है, तो इसे कचरे में एकत्र किया जा सकता है। यदि ऑब्जेक्ट अभी भी उपयोग में है, तो यह पुरानी वस्तुओं के स्थान पर चला जाता है, जिसे कम बार साफ किया जाता है। हालांकि, कुछ बिंदु पर, पुरानी वस्तुओं को हटा दिया जाता है।


यह एक स्वचालित कचरा कलेक्टर कैसे काम करता है - यह इस आधार पर वस्तुओं को साफ करता है कि उनके लिए कोई लिंक नहीं हैं। ये दो अलग-अलग एल्गोरिदम हैं।

1. स्केवेंज तेज़ है लेकिन प्रभावी नहीं है।
   
2. मार्क-स्वीप धीमा लेकिन कुशल है।
   

यदि आप Node.js में मेमोरी की खपत शुरू करते हैं, तो आपको कुछ ऐसा मिलता है।



सबसे पहले, यह अचानक बढ़ता है - यह स्केवेंज एल्गोरिथ्म का काम है। फिर एक तेज गिरावट होती है - इस मार्क-स्वीप एल्गोरिथ्म ने पुरानी वस्तुओं के स्थान पर कचरा एकत्र किया है। इस समय, सब कुछ थोड़ा धीमा होने लगता है। आप इसे नियंत्रित नहीं कर सकते , क्योंकि आप नहीं जानते कि यह कब होगा। आप केवल आकारों को समायोजित कर सकते हैं।

इसलिए, पाइपलाइन का कचरा संग्रहण चरण है जो समय लेता है।

और भी तेज?

आइए भविष्य पर गौर करें। आगे क्या करना है, कैसे तेज हो?


इस रेखा पर, ब्लॉक का आकार मोटे तौर पर उस समय से संबंधित होता है, जिसमें समय लगता है।

पहली बात जो उन लोगों के लिए ध्यान में आती है जिन्होंने बायटेकोड के बारे में सुना है - तुरंत इनपुट के लिए एक बायटेकोड सबमिट करें और इसे डीकोड करने के बजाय इसे डीकोड करें - तेज हो जाएगा!



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

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

और क्या किया जा सकता है? कल्पना कीजिए कि इस भाषा में मैनुअल मेमोरी प्रबंधन है। फिर कूड़ा उठाने वाले की जरूरत नहीं है। लाइन छोटी और तेज हो गई है।



लगता है कि यह कैसा दिखता है? WebAssembly लगभग
यह है कि यह कैसे काम करता है: मैन्युअल मेमोरी प्रबंधन, सांख्यिकीय रूप से टाइप किया गया
भाषाओं और तेजी से निष्पादन।


क्या WebAssembly एक चांदी की गोली है?


नहीं, क्योंकि यह जावास्क्रिप्ट के लिए खड़ा है। WASM अभी तक कुछ नहीं कर सकता है। उसके पास DOM API नहीं है। यह जावास्क्रिप्ट इंजन के अंदर है - उसी इंजन के अंदर! यह जावास्क्रिप्ट के माध्यम से सब कुछ करता है, इसलिए WASM आपके कोड को गति नहीं देगा । यह अलग-अलग गणनाओं को गति दे सकता है, लेकिन जावास्क्रिप्ट और WASM के बीच आपका विनिमय एक अड़चन होगा।

इसलिए, जबकि हमारी भाषा जावास्क्रिप्ट है और केवल यह है, और ब्लैक बॉक्स से कुछ मदद मिलती है।

कुल मिलाकर

तीन प्रकार के अनुकूलन को प्रतिष्ठित किया जा सकता है।

● एल्गोरिथ्म अनुकूलन

व्याचेस्लाव ईगोरोव द्वारा एक लेख " हो सकता है कि आपको अपने जेएस को गति देने के लिए जंग की आवश्यकता न हो ", जिसने कभी वी 8 विकसित किया था और अब डार्ट विकसित कर रहा है। उसकी कहानी को संक्षेप में बताएं।

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

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

● भाषा-विशिष्ट अनुकूलन

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

● इंजन-विशिष्ट अनुकूलन

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

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


किसी भी प्रकार के कठिन अनुकूलन को लागू करने की कोशिश करने की आवश्यकता नहीं है क्योंकि आप उनके बारे में सकारात्मक समीक्षा पढ़ते हैं।

इस तरह की अनुकूलन से डरना चाहिए, मेट्रिक्स को दस्तावेज़ और छोड़ना सुनिश्चित करें। आम तौर पर हमेशा मैट्रिक्स इकट्ठा करते हैं। मेट्रिक्स महत्वपूर्ण हैं!

उपयोगी लिंक:

• रिपोर्ट का सार और प्रस्तुति
• क्या मोनोमोर्फिज्म है?
• WebAssembly तेजी से क्या करता है?
• V8 बाइटकोड को समझने का तरीका
• देवशक्त: कट्टर

Frontend Conf Moscow 4 5 . 15 , , :

• (KeepSolid) , Offline First Persistent Storage
• (TradingView) WebGL WebAssembly , , API .
• , Google Docs.