जावास्क्रिप्ट में एल्गोरिदम की दक्षता को कैसे समझें और अनुकूलित करें

जावास्क्रिप्ट में एल्गोरिदम की दक्षता को कैसे समझें और अनुकूलित करें

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

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

पहला अनुमान नेटवर्क का ही था। अक्सर ऐसा ही होता है। API धीमा ही होगा, है ना? लेकिन API का रिस्पॉन्स लगभग 280 मिलीसेकंड में आ गया। बहुत बढ़िया नहीं, बहुत बुरा भी नहीं। डेटा आने के बाद भी पेज चार-पांच सेकंड के लिए रुका रहा। वह खामोशी भरा अंतराल, जिसमें ब्राउज़र बस कुछ सोच-विचार करता रहता है, असली सुराग था।

धीमी गति के लिए सब लोग दोष नहीं दे रहे थे।

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

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

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

असली उपयोगकर्ता असली डेटा लाते हैं, और असली डेटा बेबाक होता है।

डेवलपर के लैपटॉप पर, ऑर्डर हिस्ट्री स्क्रीन में शायद 50 नकली रिकॉर्ड थे। सब कुछ एकदम तुरंत हो गया। प्रोडक्शन में, एक ग्राहक के पास 18,000 पुराने ऑर्डर थे। दूसरे ग्राहक के पास अजीबोगरीब लंबे प्रोडक्ट नाम, अधूरी जानकारी, पुराने रद्द किए गए ऑर्डर और ग्राहक के नोट्स थे जो किसी ने ईमेल थ्रेड का आधा हिस्सा चिपका दिया हो, ऐसा लग रहा था। टेस्ट डेटा ठीक से काम करता है। प्रोडक्शन डेटा में बस स्नैक्स होते हैं और वो रात भर वहीं पड़ा रहता है।

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

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

कोई पुनर्लेखन नहीं। कोई फ्रेमवर्क माइग्रेशन नहीं। कोई नाटकीय भाषण नहीं कि "हमने तीन सप्ताह में फ्रंटएंड को फिर से बनाया"। बस इस बात पर ध्यान देना कि वास्तव में समय कहाँ जा रहा है।

फ्रेमवर्क को दोष देने से पहले क्या जांचना चाहिए

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

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

कुछ आम गलतियाँ जो जावास्क्रिप्ट को उसकी असलियत से कहीं अधिक जटिल बना देती हैं

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

एक और चालाकी भरी गलती: समस्या के स्वरूप पर विचार किए बिना ऐरे विधियों का उपयोग करना। map , filter , reduce और find जैसी विधियाँ पठनीय हैं, और पठनीय होना अच्छी बात है, लेकिन बड़े ऐरे पर इनका एक साथ उपयोग करने से डेटा पर कई बार पूर्ण रूप से काम करना पड़ सकता है। कभी-कभी यह ठीक है। कभी-कभी यह एक ही कमरे में बार-बार आने-जाने जैसा होता है।

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

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

व्यावहारिक आदतें जो बाद में कष्ट से बचाती हैं

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

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

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

उबाऊ अंत ही उपयोगी हिस्सा है।

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

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