जेएस कैसे काम करता है: सार सिंटैक्स पेड़, पार्सिंग और इसके अनुकूलन

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

कैसे प्रोग्रामिंग भाषाएं हैं

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

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

अमूर्त वाक्यविन्यास पेड़ों का उपयोग करना

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

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

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

पार्सिंग जावास्क्रिप्ट

आइए बात करते हैं कि अमूर्त सिंटैक्स के पेड़ कैसे बनाए जाते हैं। एक उदाहरण के रूप में, एक साधारण जावास्क्रिप्ट फ़ंक्शन पर विचार करें:

function foo(x) {    if (x > 10) {        var a = 2;        return a * x;    }    return x + 10; } 

पार्सर एक अमूर्त वाक्यविन्यास वृक्ष का निर्माण करेगा, जिसे निम्नलिखित आकृति में योजनाबद्ध रूप से दर्शाया गया है।


सार सिंटेक्स ट्री

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

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

इस ड्राइंग को करीब से देखें, शायद आपको वहां कुछ दिलचस्प दिखाई देगा।


जेएस कोड निष्पादित करने में समय व्यतीत हुआ

आप देखते हैं? यदि नहीं, तो फिर से देखें। दरअसल, हम इस तथ्य के बारे में बात कर रहे हैं कि, औसतन, ब्राउज़र जेएस कोड को पार्स करने में 15-20% समय व्यतीत करते हैं। और यह कुछ सशर्त डेटा नहीं है। यहां वास्तविक वेब परियोजनाओं के काम के बारे में सांख्यिकीय जानकारी है जो एक तरह से या किसी अन्य तरीके से जावास्क्रिप्ट का उपयोग करते हैं। शायद 15% का आंकड़ा आपको इतना बड़ा नहीं लगेगा, लेकिन मेरा विश्वास करो, यह बहुत कुछ है। एक विशिष्ट एक-पृष्ठ एप्लिकेशन जावास्क्रिप्ट कोड के लगभग 0.4 एमबी को लोड करता है, और इस कोड को पार्स करने के लिए ब्राउज़र को लगभग 370 एमएस की आवश्यकता होती है। फिर, आप कह सकते हैं कि चिंता की कोई बात नहीं है। और हाँ, यह अकेले ज्यादा नहीं है। हालांकि, यह मत भूलो कि कोड को पार्स करने और एएसटी में बदलने के लिए यह सिर्फ समय है। इसमें कोड को निष्पादित करने में लगने वाला समय या पृष्ठ के लोडिंग के साथ आने वाले अन्य कार्यों को हल करने में लगने वाला समय शामिल नहीं है, उदाहरण के लिए, HTML और CSS को संसाधित करने और पृष्ठ को रेंडर करने के कार्य। इसके अलावा, हम केवल डेस्कटॉप ब्राउज़रों के बारे में बात कर रहे हैं। मोबाइल सिस्टम के मामले में अभी भी बदतर है। विशेष रूप से, मोबाइल उपकरणों पर समान कोड के लिए पार्सिंग समय डेस्कटॉप पर 2-5 गुना अधिक हो सकता है। निम्नलिखित आकृति पर एक नज़र डालें।


विभिन्न उपकरणों पर 1 एमबी जेएस-कोड का पार्सिंग समय

यहां विभिन्न मोबाइल और डेस्कटॉप उपकरणों पर 1 एमबी जेएस कोड को पार्स करने के लिए आवश्यक समय है।

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


एक ब्राउज़र में डेवलपर टूल का उपयोग करके वेबसाइट विश्लेषण

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

पार्सिंग ऑप्टिमाइज़ेशन और जेएस इंजन

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

V8 इंजन स्ट्रीमिंग स्क्रिप्ट और कोड कैशिंग का समर्थन करता है। इस मामले में, स्ट्रीमिंग को इस तथ्य के रूप में समझा जाता है कि सिस्टम असिंक्रोनस रूप से भरी हुई स्क्रिप्ट को पार्स करने में लगा हुआ है, और स्क्रिप्ट, जिसके निष्पादन में देरी हो रही है, एक अलग थ्रेड में, कोड को लोड करना शुरू होने के क्षण से ऐसा करना शुरू करना। यह इस तथ्य की ओर जाता है कि स्क्रिप्ट को लोड करने के पूरा होने के साथ पार्सिंग लगभग एक साथ समाप्त होती है, जो काम के लिए पेज तैयार करने के लिए आवश्यक समय में लगभग 10% की कमी देती है।

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

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

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

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

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

वेब एप्लिकेशन तैयारी का समय कम करें

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

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

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

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

आइए इन तंत्रों के संचालन को दर्शाते हुए एक उदाहरण की जाँच करें। मान लीजिए कि हमारे पास निम्नलिखित जेएस कोड है:

 function foo() {   function bar(x) {       return x + 10;   }   function baz(x, y) {       return x + y;   }   console.log(baz(100, 200)); } 

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

• एक bar फ़ंक्शन की घोषणा करना जो एक तर्क ( x ) लेता है। इस फ़ंक्शन में एक रिटर्न कमांड है, यह x और 10 को जोड़ने का परिणाम देता है।
• एक baz फ़ंक्शन की घोषणा करना जो दो तर्क ( x और y ) लेता है। उसके पास एक वापसी आदेश भी है, वह x और y को जोड़ने का परिणाम देता है।
• दो तर्कों के साथ baz समारोह में कॉल करना - 100 और 200।
• एक तर्क के साथ console.log फ़ंक्शन को कॉल करना, जो कि पहले कहे गए फ़ंक्शन द्वारा लौटाया गया मान है।

यहाँ है कि यह कैसा दिखता है।


अनुकूलन लागू किए बिना नमूना कोड पार्स करने का परिणाम

यहाँ क्या चल रहा है, इसके बारे में बात करते हैं। पार्सर bar फ़ंक्शन की घोषणा, baz फ़ंक्शन की घोषणा, baz फ़ंक्शन को कॉल और baz फ़ंक्शन को कॉल देखता है। जाहिर है, कोड के इस टुकड़े को पार्स करते हुए, पार्सर एक कार्य का सामना करेगा जिसका निष्पादन इस कार्यक्रम के परिणामों को प्रभावित नहीं करेगा। यह फ़ंक्शन bar का विश्लेषण करने के बारे में है। इस फ़ंक्शन का विश्लेषण व्यावहारिक क्यों नहीं है? बात यह है कि bar कोड, कम से कम प्रस्तुत कोड के टुकड़े में, कभी नहीं कहा जाता है। यह सरल उदाहरण दूर की कौड़ी लग सकता है, लेकिन कई वास्तविक अनुप्रयोगों में बड़ी संख्या में फ़ंक्शन होते हैं जिन्हें कभी नहीं कहा जाता है।

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

नतीजतन, पिछले उदाहरण में, वास्तविक पार्सर निम्नलिखित योजना के समान एक संरचना बनाएगा।


अनुकूलन के साथ पार्सिंग उदाहरण कोड का परिणाम

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

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

उदाहरण के लिए, जावास्क्रिप्ट में मॉड्यूल को लागू करने के लिए एक बहुत ही सामान्य पैटर्न है:

 var myModule = (function() {   //      //    })(); 

अधिकांश आधुनिक जेएस पार्सर इस पैटर्न को पहचानते हैं; उनके लिए यह एक संकेत है कि मॉड्यूल के अंदर स्थित कोड को पूरी तरह से विश्लेषण करने की आवश्यकता है।

लेकिन क्या होगा अगर पार्सर हमेशा आलसी पार्सिंग का इस्तेमाल करते हैं? यह, दुर्भाग्य से, एक अच्छा विचार नहीं है। तथ्य यह है कि इस दृष्टिकोण के साथ, यदि कुछ कोड को जितनी जल्दी हो सके निष्पादित करने की आवश्यकता है, तो हम सिस्टम में मंदी का सामना करेंगे। पार्सर आलसी पार्सिंग का एक पास प्रदर्शन करेगा, जिसके बाद यह तुरंत पूरी तरह से विश्लेषण करना शुरू कर देगा कि जितनी जल्दी हो सके क्या करना है। यह दृष्टिकोण की तुलना में लगभग 50% मंदी की ओर ले जाएगा जब पार्सर तुरंत सबसे महत्वपूर्ण कोड को पूरी तरह से पार्स करना शुरू कर देता है।

कोड अनुकूलन, इसके विश्लेषण की विशेषताओं को ध्यान में रखते हुए

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

मान लें कि हमारे पास एक फ़ंक्शन foo :

 function foo(x) {   return x * 10; } 

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

सबसे पहले, फंक्शन को एक वेरिएबल में सेव करें:

 var foo = function foo(x) {   return x * 10; }; 

कृपया ध्यान दें कि हमने function कीवर्ड और शुरुआती ब्रैकेट के बीच प्रारंभिक फ़ंक्शन नाम छोड़ दिया है। यह नहीं कहा जा सकता है कि यह पूरी तरह से आवश्यक है, लेकिन यह सिर्फ ऐसा करने के लिए अनुशंसित है, क्योंकि यदि फ़ंक्शन चल रहा है, तो एक अपवाद फेंक दिया जाता है, तो आप स्टैक ट्रेस डेटा में फ़ंक्शन का नाम देख सकते हैं, <anonymous> ।

उपरोक्त परिवर्तन के बाद, पार्सर आलसी पार्सिंग का उपयोग करना जारी रखेगा। इसे बदलने के लिए, एक छोटा विवरण पर्याप्त है। फ़ंक्शन को कोष्ठक में संलग्न किया जाना चाहिए:

 var foo = (function foo(x) {   return x * 10; }); 

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

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

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

तो, मान लीजिए कि हम किसी भी चीज़ के बारे में सोचे बिना, और हमारे पास निम्नलिखित कोड टुकड़ा है:

 (function() {   console.log('Hello, World!'); })(); 

यह काफी सामान्य दिखता है, यह अपेक्षा के अनुसार काम करता है, इसे जल्दी से निष्पादित किया जाता है, क्योंकि पार्सर function कीवर्ड के सामने उद्घाटन ब्रैकेट पाता है। अभी तक तो अच्छा है। , , , :

 !function(){console.log('Hello, World!')}(); 

, , . , - .

, , . , , , . , , , . , , . Optimize.js. Optimize.js, :

 !(function(){console.log('Hello, World!')})(); 

, . , . , , , — .

, JS- — , . ? , , , , . , , , , JS- , . , , , -, . - . , , . , , , , . , JS- , , V8 , , . .

, -:

• . .
• , .
• , , , JS-. , , .
• DeviceTiming , .
• Optimize.js , , .

परिणाम

, , SessionStack , , -, . , . — . , — , -, , , .

प्रिय पाठकों! - JavaScript-?