भले ही, आपने किसी भी तरह का ऐप्लिकेशन डेवलप किया हो, उसकी परफ़ॉर्मेंस को ऑप्टिमाइज़ करना और यह पक्का करना कि वह तेज़ी से लोड हो और आसानी से इंटरैक्ट किया जा सके, यह उपयोगकर्ता अनुभव और ऐप्लिकेशन की सफलता के लिए ज़रूरी है. ऐसा करने का एक तरीका यह है कि प्रोफ़ाइलिंग टूल का इस्तेमाल करके, किसी ऐप्लिकेशन की गतिविधि की जांच की जाए. इससे यह पता चलता है कि किसी समयावधि के दौरान, ऐप्लिकेशन के अंदर क्या हो रहा है. DevTools में मौजूद परफ़ॉर्मेंस पैनल, वेब ऐप्लिकेशन की परफ़ॉर्मेंस का विश्लेषण करने और उसे ऑप्टिमाइज़ करने के लिए एक बेहतरीन प्रोफ़ाइलिंग टूल है. अगर आपका ऐप्लिकेशन Chrome में चल रहा है, तो यह आपको इस बारे में पूरी जानकारी देता है कि आपका ऐप्लिकेशन चलने के दौरान ब्राउज़र क्या कर रहा है. इस गतिविधि को समझने से, आपको पैटर्न, रुकावटों, और परफ़ॉर्मेंस हॉटस्पॉट की पहचान करने में मदद मिल सकती है. इन परफ़ॉर्मेंस हॉटस्पॉट को ठीक करके, परफ़ॉर्मेंस को बेहतर बनाया जा सकता है.
यहां दिए गए उदाहरण में, परफ़ॉर्मेंस पैनल का इस्तेमाल करने का तरीका बताया गया है.
प्रोफ़ाइल बनाने की हमारी स्थिति को सेट अप करना और फिर से बनाना
हाल ही में, हमने परफ़ॉर्मेंस पैनल को ज़्यादा बेहतर बनाने का लक्ष्य सेट किया था. खास तौर पर, हम चाहते थे कि यह परफ़ॉर्मेंस का ज़्यादा डेटा तेज़ी से लोड करे. उदाहरण के लिए, लंबे समय तक चलने वाली या जटिल प्रोसेस की प्रोफ़ाइलिंग करने या ज़्यादा जानकारी वाले डेटा को कैप्चर करने पर ऐसा होता है. ऐसा करने के लिए, यह समझना ज़रूरी था कि ऐप्लिकेशन कैसे परफ़ॉर्म कर रहा था और क्यों उसने ऐसा किया. इसके लिए, प्रोफ़ाइलिंग टूल का इस्तेमाल किया गया.
जैसा कि आपको पता होगा, DevTools एक वेब ऐप्लिकेशन है. इसलिए, परफ़ॉर्मेंस पैनल का इस्तेमाल करके, इसकी प्रोफ़ाइल बनाई जा सकती है. इस पैनल की प्रोफ़ाइल बनाने के लिए, DevTools खोलें. इसके बाद, उससे जुड़ा कोई दूसरा DevTools इंस्टेंस खोलें. Google में, इस सेटअप को DevTools-on-DevTools कहा जाता है.
सेटअप तैयार होने के बाद, जिस स्थिति की प्रोफ़ाइल बनानी है उसे फिर से बनाया जाना चाहिए और रिकॉर्ड किया जाना चाहिए. भ्रम से बचने के लिए, ओरिजनल DevTools विंडो को "पहला DevTools इंस्टेंस" कहा जाएगा. साथ ही, पहले इंस्टेंस की जांच करने वाली विंडो को "दूसरा DevTools इंस्टेंस" कहा जाएगा.
दूसरे DevTools इंस्टेंस पर, परफ़ॉर्मेंस पैनल, प्रोफ़ाइल लोड करने वाली स्थिति को फिर से बनाने के लिए पहले DevTools इंस्टेंस को देखता है. इसे अब से परफ़ॉर्मेंस पैनल कहा जाएगा.
दूसरे DevTools इंस्टेंस पर लाइव रिकॉर्डिंग शुरू होती है, जबकि पहले इंस्टेंस पर, डिस्क पर मौजूद फ़ाइल से प्रोफ़ाइल लोड होती है. बड़ी फ़ाइल को लोड करने का मकसद, बड़े इनपुट को प्रोसेस करने की परफ़ॉर्मेंस की सटीक प्रोफ़ाइल बनाना है. जब दोनों इंस्टेंस लोड हो जाते हैं, तो परफ़ॉर्मेंस प्रोफ़ाइलिंग का डेटा, परफ़ॉर्मेंस पैनल के दूसरे DevTools इंस्टेंस में दिखता है. इसे आम तौर पर ट्रेस कहा जाता है.
शुरुआती स्थिति: सुधार के अवसरों की पहचान करना
लोड होने के बाद, अगले स्क्रीनशॉट में हमारे दूसरे परफ़ॉर्मेंस पैनल इंस्टेंस पर ये चीज़ें देखी गईं. मुख्य थ्रेड की गतिविधि पर फ़ोकस करें. यह मुख्य लेबल वाले ट्रैक में दिखती है. इससे पता चलता है कि फ़्लेम चार्ट में गतिविधि के पांच बड़े ग्रुप हैं. इनमें वे टास्क शामिल होते हैं जिनमें लोड होने में सबसे ज़्यादा समय लग रहा है. इन टास्क को पूरा करने में करीब 10 सेकंड लगे. नीचे दिए गए स्क्रीनशॉट में, परफ़ॉर्मेंस पैनल का इस्तेमाल इनमें से हर गतिविधि ग्रुप पर फ़ोकस करने के लिए किया गया है, ताकि यह देखा जा सके कि क्या मिल सकता है.
पहला गतिविधि ग्रुप: ग़ैर-ज़रूरी काम
इससे पता चला कि गतिविधि का पहला ग्रुप, लेगसी कोड था, जो अब भी चल रहा था, लेकिन इसकी ज़रूरत नहीं थी. असल में, processThreadEvents लेबल वाले हरे ब्लॉक में मौजूद सभी चीज़ें बेकार थीं. यह एक आसान काम था. उस फ़ंक्शन कॉल को हटाने से, करीब 1.5 सेकंड का समय बच गया. कूल!
दूसरा ऐक्टिविटी ग्रुप
दूसरे गतिविधि ग्रुप में, समस्या का समाधान पहले ग्रुप की तरह आसान नहीं था. buildProfileCalls को करीब 0.5 सेकंड लगे और यह ऐसा टास्क नहीं था जिसे टाला जा सकता था.
हमने ज़्यादा जानकारी पाने के लिए, परफ़ॉर्मेंस पैनल में मेमोरी विकल्प चालू किया. इससे हमें पता चला कि buildProfileCalls गतिविधि भी बहुत ज़्यादा मेमोरी का इस्तेमाल कर रही थी. यहां, यह देखा जा सकता है कि buildProfileCalls के चलने के दौरान, नीले रंग का लाइन ग्राफ़ अचानक कैसे बढ़ जाता है. इससे मेमोरी लीक होने की आशंका का पता चलता है.
इस संदेह की जांच करने के लिए, हमने मेमोरी पैनल का इस्तेमाल किया. यह DevTools में मौजूद एक पैनल है, जो परफ़ॉर्मेंस पैनल में मौजूद मेमोरी ड्रॉअर से अलग है. मेमोरी पैनल में, "ऐलोकेशन सैंपलिंग" प्रोफ़ाइलिंग टाइप चुना गया था. इससे, परफ़ॉर्मेंस पैनल के लिए हीप स्नैपशॉट रिकॉर्ड किया गया, जो सीपीयू प्रोफ़ाइल को लोड करता है.
यहां दिया गया स्क्रीनशॉट, इकट्ठा किया गया ढेर का स्नैपशॉट दिखाता है.
इस ढेर के स्नैपशॉट से पता चला कि Set क्लास बहुत ज़्यादा मेमोरी का इस्तेमाल कर रही थी. कॉल पॉइंट की जांच करने पर, हमें पता चला कि हम ज़रूरत से ज़्यादा ऑब्जेक्ट के लिए, Set टाइप की प्रॉपर्टी असाइन कर रहे थे. इस वजह से, ज़्यादा मेमोरी का इस्तेमाल होता था और ऐप्लिकेशन क्रैश हो जाता था.
सेट, यूनीक आइटम को स्टोर करने के लिए काम के होते हैं. साथ ही, ये ऐसे ऑपरेशन उपलब्ध कराते हैं जो उनके कॉन्टेंट की यूनीकनेस का इस्तेमाल करते हैं. जैसे, डेटासेट को डुप्लीकेट कॉपी से हटाना और ज़्यादा असरदार लुकअप उपलब्ध कराना. हालांकि, ये सुविधाएं ज़रूरी नहीं थीं, क्योंकि सेव किए गए डेटा के सोर्स से अलग होने की गारंटी थी. इसलिए, सेट की ज़रूरत नहीं थी. मेमोरी के बंटवारे को बेहतर बनाने के लिए, प्रॉपर्टी टाइप को Set से बदलकर प्लैन ऐरे कर दिया गया. इस बदलाव को लागू करने के बाद, ढेर का एक और स्नैपशॉट लिया गया और मेमोरी के कम सेट किए गए हिस्से को देखा गया. इस बदलाव से, ऐप्लिकेशन की स्पीड में काफ़ी सुधार नहीं हुआ. हालांकि, इसका एक फ़ायदा यह हुआ कि ऐप्लिकेशन कम क्रैश हुआ.
तीसरा गतिविधि ग्रुप: डेटा स्ट्रक्चर के फ़ायदे और नुकसान को तौलना
तीसरा सेक्शन खास है: फ़्लेम चार्ट में देखा जा सकता है कि इसमें छोटे, लेकिन लंबे कॉलम होते हैं. ये कॉलम, डीप फ़ंक्शन कॉल और इस मामले में डीप रीकर्सन को दिखाते हैं. कुल मिलाकर, यह सेक्शन करीब 1.4 सेकंड तक चला. इस सेक्शन के सबसे नीचे देखकर पता चला कि इन कॉलम की चौड़ाई, एक फ़ंक्शन की अवधि से तय होती है: appendEventAtLevel. इससे पता चलता है कि यह एक समस्या हो सकती है
appendEventAtLevel फ़ंक्शन को लागू करने के दौरान, एक बात खास तौर पर ध्यान में आई. इनपुट में मौजूद हर डेटा एंट्री (जिसे कोड में "इवेंट" कहा जाता है) के लिए, एक मैप में एक आइटम जोड़ा गया था. यह मैप, टाइमलाइन एंट्री की वर्टिकल पोज़िशन को ट्रैक करता था. यह समस्या थी, क्योंकि स्टोर किए गए आइटम की संख्या बहुत ज़्यादा थी. Maps, कीवर्ड के आधार पर खोजने की सुविधा को तेज़ी से पूरा करता है. हालांकि, यह सुविधा बिना किसी शुल्क के नहीं मिलती. जैसे-जैसे मैप बड़ा होता जाता है, उसमें डेटा जोड़ना महंगा हो सकता है. ऐसा, डेटा को फिर से प्रोसेस करने की वजह से होता है. यह लागत तब दिखती है, जब मैप में एक के बाद एक कई आइटम जोड़े जाते हैं.
/**
* Adds an event to the flame chart data at a defined vertical level.
*/
function appendEventAtLevel (event, level) {
// ...
const index = data.length;
data.push(event);
this.indexForEventMap.set(event, index);
// ...
}
हमने एक और तरीके का इस्तेमाल किया, जिसमें हमें फ़्लेम चार्ट में हर एंट्री के लिए, मैप में आइटम जोड़ने की ज़रूरत नहीं पड़ी. इसमें काफ़ी सुधार हुआ. इससे यह पुष्टि हुई कि समस्या, मैप में सारा डेटा जोड़ने से होने वाले ओवरहेड से जुड़ी थी. गतिविधि ग्रुप को पूरा होने में लगने वाला समय, 1.4 सेकंड से घटकर 200 मिलीसेकंड हो गया.
इससे पहले:
इसके बाद:
चौथा गतिविधि ग्रुप: डुप्लीकेट काम से बचने के लिए, ज़रूरी नहीं होने वाले काम और कैश मेमोरी में सेव किए गए डेटा को बाद में करने की सुविधा
इस विंडो पर ज़ूम इन करके, यह देखा जा सकता है कि फ़ंक्शन कॉल के दो ब्लॉक लगभग एक जैसे हैं. कॉल किए गए फ़ंक्शन के नाम को देखकर, यह अनुमान लगाया जा सकता है कि इन ब्लॉक में ऐसा कोड है जो ट्री बना रहा है. उदाहरण के लिए, refreshTree या buildChildren जैसे नामों के साथ. असल में, इससे जुड़ा कोड ही पैनल के सबसे नीचे मौजूद ड्रॉअर में ट्री व्यू बनाता है. दिलचस्प बात यह है कि ये ट्री व्यू, लोड होने के तुरंत बाद नहीं दिखते. इसके बजाय, उपयोगकर्ता को ट्री व्यू चुनना होगा, ताकि ट्री दिखाए जा सकें. ट्री व्यू के तौर पर, ड्रॉअर में "बॉटम-अप", "कॉल ट्री", और "इवेंट लॉग" टैब चुने जा सकते हैं. इसके अलावा, स्क्रीनशॉट से पता चलता है कि ट्री बनाने की प्रोसेस दो बार पूरी की गई.
हमें इस इमेज में दो समस्याएं मिली हैं:
- कोई ग़ैर-ज़रूरी टास्क, लोड होने में लगने वाले समय की परफ़ॉर्मेंस में रुकावट डाल रहा था. उपयोगकर्ताओं को हमेशा इसके आउटपुट की ज़रूरत नहीं होती. इसलिए, प्रोफ़ाइल लोड करने के लिए यह टास्क ज़रूरी नहीं है.
- इन टास्क के नतीजे कैश मेमोरी में सेव नहीं किए गए थे. इसलिए, डेटा में कोई बदलाव न होने के बावजूद, पेड़ों की संख्या दो बार कैलकुलेट की गई.
हमने ट्री व्यू की गिनती को तब तक के लिए रोक दिया है, जब तक उपयोगकर्ता मैन्युअल तरीके से ट्री व्यू नहीं खोलता. सिर्फ़ तब इन पेड़ों को बनाने की कीमत चुकाने की ज़रूरत है. इसे दो बार चलाने में कुल 3.4 सेकंड लगे. इसलिए, इसे बाद में लोड करने से, लोड होने में लगने वाले समय में काफ़ी फ़र्क़ पड़ा. हम इस तरह के टास्क को कैश मेमोरी में सेव करने की सुविधा पर भी काम कर रहे हैं.
पांचवां गतिविधि ग्रुप: जब भी हो सके, कॉल की जटिल हैरारकी से बचें
इस ग्रुप को ध्यान से देखने पर, यह साफ़ तौर पर पता चला कि किसी खास कॉल चेन को बार-बार ट्रिगर किया जा रहा था. यही पैटर्न, फ़्लेम चार्ट में अलग-अलग जगहों पर छह बार दिखता है. साथ ही, इस विंडो की कुल अवधि करीब 2.4 सेकंड थी!
कई बार कॉल किया जाने वाला मिलता-जुलता कोड, "मिनीमैप" (पैनल में सबसे ऊपर टाइमलाइन गतिविधि की खास जानकारी) पर रेंडर किए जाने वाले डेटा को प्रोसेस करता है. यह साफ़ नहीं था कि ऐसा कई बार क्यों हो रहा था, लेकिन ऐसा छह बार ज़रूर नहीं होना चाहिए! असल में, अगर कोई दूसरी प्रोफ़ाइल लोड नहीं की जाती है, तो कोड का आउटपुट मौजूदा ही रहना चाहिए. सिद्धांत रूप से, कोड सिर्फ़ एक बार चलना चाहिए.
जांच करने पर पता चला कि लोडिंग पाइपलाइन के कई हिस्सों ने सीधे या किसी दूसरे तरीके से, मिनीमैप का हिसाब लगाने वाले फ़ंक्शन को कॉल किया था. इस वजह से, उससे जुड़े कोड को कॉल किया गया था. ऐसा इसलिए हुआ, क्योंकि समय के साथ प्रोग्राम के कॉल ग्राफ़ की जटिलता बढ़ गई और इस कोड में अनजाने में ज़्यादा डिपेंडेंसी जोड़ दी गईं. इस समस्या को तुरंत ठीक नहीं किया जा सकता. इसे ठीक करने का तरीका, कोडबेस के आर्किटेक्चर पर निर्भर करता है. हमारे मामले में, हमें कॉल के लेआउट को थोड़ा आसान बनाना पड़ा. साथ ही, एक जांच जोड़नी पड़ी, ताकि इनपुट डेटा में कोई बदलाव न होने पर कोड को न चलाया जाए. इसे लागू करने के बाद, हमें टाइमलाइन का यह नया रूप मिला:
ध्यान दें कि मिनीमैप रेंडरिंग एक बार नहीं, बल्कि दो बार होती है. ऐसा इसलिए होता है, क्योंकि हर प्रोफ़ाइल के लिए दो मिनीमैप बनाए जाते हैं: एक पैनल में सबसे ऊपर मौजूद खास जानकारी के लिए और दूसरा ड्रॉप-डाउन मेन्यू के लिए. यह मेन्यू, इतिहास से वह प्रोफ़ाइल चुनता है जो फ़िलहाल दिख रही है. इस मेन्यू के हर आइटम में, उस प्रोफ़ाइल की खास जानकारी होती है जिसे यह चुनता है. इसके बावजूद, इन दोनों में एक जैसा कॉन्टेंट है. इसलिए, इनमें से किसी एक का इस्तेमाल दूसरे के लिए किया जा सकता है.
इन दोनों मिनीमैप को कैनवस पर बनाया गया है. इसलिए, drawImage कैनवस की सुविधा का इस्तेमाल करके, कोड को सिर्फ़ एक बार चलाया गया, ताकि कुछ समय बचाया जा सके. इस वजह से, ग्रुप की अवधि 2.4 सेकंड से घटकर 140 मिलीसेकंड हो गई.
नतीजा
इन सभी सुधारों (और कुछ अन्य छोटे सुधारों) को लागू करने के बाद, प्रोफ़ाइल लोड होने में लगने वाले समय की टाइमलाइन में यह बदलाव हुआ:
इससे पहले:
इसके बाद:
सुधारों के बाद, लोड होने में लगने वाला समय दो सेकंड हो गया. इसका मतलब है कि ज़्यादा मेहनत किए बिना लगभग 80%की बढ़ोतरी हासिल की गई. ऐसा इसलिए हुआ, क्योंकि ज़्यादातर सुधार तुरंत किए गए थे. शुरुआत में, यह पता लगाना ज़रूरी था कि क्या करना है. इसके लिए, परफ़ॉर्मेंस पैनल सबसे सही टूल था.
यह भी ध्यान रखना ज़रूरी है कि ये संख्याएं, खास तौर पर उस प्रोफ़ाइल के लिए हैं जिसका इस्तेमाल स्टडी के विषय के तौर पर किया जा रहा है. यह प्रोफ़ाइल हमारे लिए दिलचस्प थी, क्योंकि यह काफ़ी बड़ी थी. हालांकि, प्रोसेसिंग पाइपलाइन हर प्रोफ़ाइल के लिए एक जैसी होती है. इसलिए, परफ़ॉर्मेंस पैनल में लोड की गई हर प्रोफ़ाइल पर, बेहतर परफ़ॉर्मेंस का असर पड़ता है.
सीखने वाली अहम बातें
अपने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, इन नतीजों से कुछ बातें सीखी जा सकती हैं:
1. रनटाइम परफ़ॉर्मेंस पैटर्न की पहचान करने के लिए, प्रोफ़ाइलिंग टूल का इस्तेमाल करना
प्रोफ़ाइलिंग टूल, यह समझने में काफ़ी मददगार होते हैं कि आपका ऐप्लिकेशन चलने के दौरान उसमें क्या हो रहा है. खास तौर पर, परफ़ॉर्मेंस को बेहतर बनाने के अवसरों की पहचान करने के लिए. Chrome DevTools में मौजूद परफ़ॉर्मेंस पैनल, वेब ऐप्लिकेशन के लिए एक बेहतरीन विकल्प है. इसकी वजह यह है कि यह ब्राउज़र में मौजूद नेटिव वेब प्रोफ़ाइलिंग टूल है. साथ ही, इसे वेब प्लैटफ़ॉर्म की नई सुविधाओं के साथ अप-टू-डेट रखने के लिए लगातार अपडेट किया जाता है. साथ ही, यह अब काफ़ी तेज़ हो गया है! 😉
ऐसे सैंपल का इस्तेमाल करें जिन्हें प्रतिनिधि वर्कलोड के तौर पर इस्तेमाल किया जा सकता है और देखें कि आपको क्या मिल सकता है!
2. कॉल की जटिल हैरारकी से बचना
अगर हो सके, तो अपने कॉल ग्राफ़ को बहुत जटिल न बनाएं. कॉल की जटिल हैरारकी की वजह से, परफ़ॉर्मेंस में गिरावट आना आसान है. साथ ही, यह समझना मुश्किल हो जाता है कि आपका कोड इस तरह से क्यों चल रहा है. इस वजह से, कोड में सुधार करना मुश्किल हो जाता है.
3. ग़ैर-ज़रूरी काम की पहचान करना
आम तौर पर, पुराने कोडबेस में ऐसा कोड होता है जिसकी अब ज़रूरत नहीं होती. हमारे मामले में, लेगसी और ग़ैर-ज़रूरी कोड, लोड होने में लगने वाले कुल समय का ज़्यादातर हिस्सा ले रहा था. इसे हटाना सबसे आसान था.
4. डेटा स्ट्रक्चर का सही तरीके से इस्तेमाल करना
परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, डेटा स्ट्रक्चर का इस्तेमाल करें. हालांकि, यह तय करते समय कि किस तरह के डेटा स्ट्रक्चर का इस्तेमाल करना है, यह भी समझें कि हर तरह के डेटा स्ट्रक्चर की लागत और फ़ायदे क्या हैं. यह सिर्फ़ डेटा स्ट्रक्चर के लिए जगह की जटिलता नहीं है, बल्कि लागू होने वाले ऑपरेशन के लिए समय की जटिलता भी है.
5. जटिल या बार-बार होने वाली कार्रवाइयों के लिए, डुप्लीकेट काम से बचने के लिए नतीजों को कैश मेमोरी में सेव करना
अगर किसी ऑपरेशन को लागू करने में ज़्यादा समय लगता है, तो अगली बार ज़रूरत पड़ने पर उसके नतीजों को सेव करना सही रहता है. अगर कोई कार्रवाई कई बार की जाती है, तो भी ऐसा करना सही होता है. भले ही, हर बार की जाने वाली कार्रवाई की लागत ज़्यादा न हो.
6. ग़ैर-ज़रूरी काम को रोकना
अगर किसी टास्क के आउटपुट की तुरंत ज़रूरत नहीं है और टास्क को पूरा करने में ज़्यादा समय लग रहा है, तो उसे टाल दें. इसके लिए, टास्क को ज़रूरत पड़ने पर ही कॉल करें.
7. बड़े इनपुट के लिए बेहतर एल्गोरिदम का इस्तेमाल करना
बड़े इनपुट के लिए, समय की सबसे कम खपत करने वाले एल्गोरिदम का इस्तेमाल करना ज़रूरी हो जाता है. हमने इस उदाहरण में इस कैटगरी पर ध्यान नहीं दिया है, लेकिन इसकी अहमियत को कम नहीं आंका जा सकता.
8. बोनस: अपनी पाइपलाइन का बेंचमार्क बनाना
यह पक्का करने के लिए कि आपका कोड तेज़ी से काम करता रहे, उसके व्यवहार पर नज़र रखें और उसकी तुलना स्टैंडर्ड से करें. इस तरह, आपके पास पहले से ही मॉडल की परफ़ॉर्मेंस में गिरावट की पहचान करने और उसे बेहतर बनाने का विकल्प होता है. इससे, आपको लंबे समय तक मॉडल को बेहतर बनाने में मदद मिलती है.