भले ही, आप किसी भी तरह का ऐप्लिकेशन डेवलप कर रहे हों, लेकिन उसकी परफ़ॉर्मेंस को ऑप्टिमाइज़ करना और यह पक्का करना कि वह तेज़ी से लोड हो रहा हो और बिना रुकावट के इंटरैक्शन की सुविधा दे, उपयोगकर्ता अनुभव और ऐप्लिकेशन की सफलता के लिए बहुत ज़रूरी है. ऐसा करने का एक तरीका यह है कि किसी ऐप्लिकेशन की गतिविधि की जांच की जाए. इसके लिए, प्रोफ़ाइलिंग टूल का इस्तेमाल किया जा सकता है. इससे यह पता लगाया जा सकता है कि उस ऐप्लिकेशन में क्या हो रहा है. DevTools में परफ़ॉर्मेंस पैनल एक बेहतरीन प्रोफ़ाइलिंग टूल है. इसकी मदद से, वेब ऐप्लिकेशन की परफ़ॉर्मेंस का विश्लेषण किया जा सकता है और उसे ऑप्टिमाइज़ किया जा सकता है. अगर आपका ऐप्लिकेशन Chrome में चल रहा है, तो यह आपको इस बारे में विज़ुअल की ज़्यादा जानकारी देता है कि आपका ऐप्लिकेशन जिस समय काम कर रहा है वह ब्राउज़र में क्या कर रहा है. इस गतिविधि को समझने से, आपको पैटर्न, रुकावटों, और परफ़ॉर्मेंस हॉटस्पॉट की पहचान करने में मदद मिल सकती है. इन्हें अपनाकर अपनी परफ़ॉर्मेंस को बेहतर बनाया जा सकता है.
इस उदाहरण में, परफ़ॉर्मेंस पैनल का इस्तेमाल करने के बारे में जानकारी दी गई है.
प्रोफ़ाइलिंग की स्थिति को सेट अप करना और उसे फिर से बनाना
हाल ही में, हमने परफ़ॉर्मेंस पैनल को ज़्यादा बेहतर बनाने का लक्ष्य तय किया है. खास तौर पर, हम चाहते थे कि यह ज़्यादा तेज़ी से परफ़ॉर्मेंस डेटा लोड करे. उदाहरण के लिए, लंबे समय तक चलने वाली या जटिल प्रोसेस की प्रोफ़ाइल बनाते समय या बहुत ज़्यादा जानकारी वाला डेटा कैप्चर करते समय, ऐसा ही होता है. इसके लिए, हमने यह समझना ज़रूरी है कि कैसे ऐप्लिकेशन की परफ़ॉर्मेंस कैसी थी और इस तरह से परफ़ॉर्मेंस क्यों इस तरह की गई. इसके लिए, प्रोफ़ाइल बनाने वाले टूल का इस्तेमाल किया जा सकता है.
जैसा कि आपको पता होगा, DevTools खुद एक वेब ऐप्लिकेशन है. इसलिए, परफ़ॉर्मेंस पैनल का इस्तेमाल करके इसकी प्रोफ़ाइल बनाई जा सकती है. इस पैनल को प्रोफ़ाइल करने के लिए, DevTools खोलें. इसके बाद, इससे जुड़े DevTools का दूसरा इंस्टेंस खोलें. Google में, इस सेटअप को DevTools-on-Dev टूल के नाम से जाना जाता है.
सेटअप तैयार होने के बाद, प्रोफ़ाइल वाली स्थिति को फिर से बनाना और रिकॉर्ड करना होगा. किसी भी तरह की उलझन से बचने के लिए, ओरिजनल DevTools विंडो को "पहला DevTools इंस्टेंस" के तौर पर दिखाया जाएगा. साथ ही, पहले इंस्टेंस की जांच करने वाली विंडो को "दूसरा DevTools इंस्टेंस" कहा जाएगा.
दूसरे DevTools इंस्टेंस पर, परफ़ॉर्मेंस पैनल—इसे यहां से परफ़ पैनल कहा जाएगा—इस स्थिति को फिर से बनाने वाला पहला DevTools इंस्टेंस दिखाता है. इससे एक प्रोफ़ाइल लोड होती है.
दूसरे DevTools इंस्टेंस पर लाइव रिकॉर्डिंग शुरू की जाती है. वहीं, पहले इंस्टेंस पर, डिस्क पर मौजूद किसी फ़ाइल से प्रोफ़ाइल लोड की जाती है. एक बड़ी फ़ाइल लोड की जाती है, ताकि बड़े इनपुट को प्रोसेस करने की परफ़ॉर्मेंस की सटीक प्रोफ़ाइल बनाई जा सके. दोनों इंस्टेंस लोड होने के बाद, परफ़ॉर्मेंस प्रोफ़ाइल डेटा को आम तौर पर trace कहा जाता है. यह प्रोफ़ाइल लोड होने वाले परफ़ पैनल के दूसरे DevTools इंस्टेंस में दिखता है.
शुरुआती स्थिति: सुधार के अवसरों की पहचान करना
लोड होने के बाद, अगले स्क्रीनशॉट में हमारे परफ़ेक्ट पैनल के दूसरे इंस्टेंस पर ये चीज़ें देखी गईं. मुख्य थ्रेड की गतिविधि पर फ़ोकस करें, जो मुख्य लेबल वाले ट्रैक में दिखती है. यह देखा जा सकता है कि फ़्लेम चार्ट में गतिविधि के पांच बड़े ग्रुप हैं. इनमें ऐसे टास्क शामिल हैं जहां कॉन्टेंट लोड होने में सबसे ज़्यादा समय लग रहा है. इन टास्क का कुल समय करीब 10 सेकंड था. नीचे दिए गए स्क्रीनशॉट में, परफ़ॉर्मेंस पैनल का इस्तेमाल इनमें से हर गतिविधि ग्रुप पर फ़ोकस करने के लिए किया गया है, ताकि यह देखा जा सके कि क्या मिल सकता है.
पहली गतिविधि का ग्रुप: गैर-ज़रूरी काम
यह साफ़ तौर पर पता चला कि गतिविधि का पहला ग्रुप लेगसी कोड था, जो अब भी चला था, लेकिन उसकी ज़रूरत नहीं थी. असल में, processThreadEvents लेबल वाले ग्रीन ब्लॉक में सब कुछ बेकार था. यह बहुत ही तेज़ काम था. उस फ़ंक्शन कॉल को हटाने से करीब 1.5 सेकंड का समय बचा. बढ़िया है!
दूसरा गतिविधि ग्रुप
दूसरे गतिविधि ग्रुप में, समाधान पहले वाले ग्रुप जितना आसान नहीं था. buildProfileCalls में करीब 0.5 सेकंड का समय लगा और इस टास्क को टाला नहीं जा सकता.
दिलचस्पी की वजह से, हमने परफ़ॉर्मेंस पैनल में मेमोरी विकल्प को चालू कर दिया, ताकि आगे की जांच की जा सके. हमें पता चला कि buildProfileCalls गतिविधि में बहुत ज़्यादा मेमोरी का इस्तेमाल हो रहा था. यहां देखा जा सकता है कि buildProfileCalls के चलने के दौरान, नीले रंग का ग्राफ़ अचानक कैसे जंप करने लगता है. इससे यह पता चलता है कि डेटा की मेमोरी में लीक हो सकता है.
इस संदेह का पता लगाने के लिए, हमने मेमोरी पैनल का इस्तेमाल किया. मेमोरी पैनल में, "ऐलोकेशन सैंपलिंग" प्रोफ़ाइलिंग टाइप को चुना गया. इससे सीपीयू प्रोफ़ाइल लोड हो रहे परफ़ पैनल के लिए हीप स्नैपशॉट रिकॉर्ड किया गया.
नीचे दिया गया स्क्रीनशॉट, इकट्ठा किए गए हीप स्नैपशॉट को दिखाता है.
इस हीप स्नैपशॉट से पता चला कि Set क्लास बहुत ज़्यादा मेमोरी का इस्तेमाल कर रही थी. कॉल पॉइंट की जांच करने पर, पता चला कि हम बहुत ज़्यादा संख्या में बनाए गए ऑब्जेक्ट को बेवजह, Set टाइप की प्रॉपर्टी असाइन कर रहे थे. इसकी वजह से लागत बढ़ रही थी और ज़्यादा मेमोरी की खपत हुई. इतना ज़्यादा कि बड़े इनपुट पर ऐप्लिकेशन क्रैश होना आम बात थी.
सेट की मदद से, अलग-अलग आइटम को स्टोर किया जा सकता है. साथ ही, इन सेट का इस्तेमाल अपने कॉन्टेंट की खासियत के हिसाब से किया जा सकता है. जैसे, डुप्लीकेट डेटासेट बनाना और बेहतर लुकअप उपलब्ध कराना. हालांकि, इन सुविधाओं की ज़रूरत नहीं थी, क्योंकि सेव किया गया डेटा सोर्स से अलग होगा. इसलिए, पहली बार में सेट की ज़रूरत नहीं थी. मेमोरी का बंटवारा बेहतर बनाने के लिए, प्रॉपर्टी के टाइप को Set से बदलकर सामान्य अरे किया गया है. इस बदलाव को लागू करने के बाद, एक और हीप स्नैपशॉट लिया गया और मेमोरी में कमी देखी गई. इस बदलाव के साथ, रफ़्तार में काफ़ी सुधार नहीं हुए. हालांकि, दूसरा फ़ायदा यह था कि ऐप्लिकेशन बार-बार क्रैश नहीं हुआ.
तीसरा गतिविधि ग्रुप: डेटा स्ट्रक्चर को ध्यान में रखकर किए जाने वाले समझौते की अहमियत
तीसरा सेक्शन खास है: फ़्लेम चार्ट में देखा जा सकता है कि इसमें पतले लेकिन लंबे कॉलम हैं, जो डीप फ़ंक्शन कॉल और इस मामले में डीप रिकर्सिंग को दिखाते हैं. कुल मिलाकर, यह सेक्शन करीब 1.4 सेकंड तक चला. इस सेक्शन के निचले हिस्से को देखने से पता चला कि इन कॉलम की चौड़ाई, एक फ़ंक्शन की अवधि से तय की गई थी: appendEventAtLevel, जिसका सुझाव था कि यह एक बॉटलनेक हो सकता है
appendEventAtLevel फ़ंक्शन को लागू करने में एक चीज़ सामने आई. इनपुट में हर एक डेटा एंट्री (जिसे कोड में "इवेंट" के नाम से जाना जाता है) के लिए, मैप में एक आइटम जोड़ा गया. इससे टाइमलाइन एंट्री की वर्टिकल पोज़िशन को ट्रैक किया जा सकता है. इससे परेशानी हुई, क्योंकि स्टोर किए गए सामान बहुत ज़्यादा थे. मैप कुंजी-आधारित लुकअप के लिए तेज़ हैं, लेकिन यह फ़ायदा मुफ़्त नहीं है. जैसे-जैसे मैप बड़ा होता जाता है, उसमें डेटा जोड़ने से यह महंगा हो सकता है. जैसे, रीहैश करने की वजह से यह महंगा हो सकता है. मैप पर बहुत सारे आइटम को एक के बाद एक जोड़ने पर, लागत साफ़ तौर पर दिखने लगती है.
/**
* 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 मिलीसेकंड कर दी गई.
नतीजा
इन सभी समाधानों को लागू करने के बाद (और यहां कुछ अन्य छोटे सुधार लागू करने के बाद), प्रोफ़ाइल लोड होने की समयावधि में इस तरह का बदलाव दिखता है:
पहले:
बाद में:
सुधारों के बाद लोड होने में 2 सेकंड का समय लगा, जिसका मतलब है कि करीब 80%का सुधार बहुत ही कम मेहनत में हासिल हुआ, क्योंकि ज़्यादातर कामों में तुरंत सुधार शामिल थे. बेशक, शुरुआत में क्या करना है, इसकी सही तरीके से पहचान करना सबसे अहम था और इसके लिए, परफ़ पैनल सही टूल था.
यह हाइलाइट करना भी ज़रूरी है कि ये आंकड़े खास तौर पर, स्टडी के लिए इस्तेमाल की जा रही प्रोफ़ाइल के लिए हैं. हमें यह प्रोफ़ाइल इसलिए दिलचस्प लगी, क्योंकि इसका साइज़ बड़ा था. हालांकि, हर प्रोफ़ाइल की प्रोसेसिंग पाइपलाइन एक जैसी होती है. इसलिए, जो सुधार किया गया है वह परफ़ पैनल में लोड की गई हर प्रोफ़ाइल पर लागू होता है.
टेकअवे
आपको अपने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के मामले में, इन नतीजों से कुछ सीखने को मिल सकते हैं:
1. रनटाइम की परफ़ॉर्मेंस के पैटर्न का पता लगाने के लिए, प्रोफ़ाइलिंग टूल का इस्तेमाल करें
प्रोफ़ाइलिंग टूल यह समझने में बहुत उपयोगी होते हैं कि आपके ऐप्लिकेशन के चलने के दौरान उसमें क्या हो रहा है, खासकर परफ़ॉर्मेंस को बेहतर बनाने के अवसरों की पहचान करने में. Chrome DevTools में परफ़ॉर्मेंस पैनल, वेब ऐप्लिकेशन के लिए बेहतरीन विकल्प है. ऐसा इसलिए है, क्योंकि यह ब्राउज़र में वेब प्रोफ़ाइल बनाने वाला मूल टूल है. साथ ही, यह वेब प्लैटफ़ॉर्म की नई सुविधाओं के साथ अप-टू-डेट रहता है. साथ ही, यह अब काफ़ी तेज़ हो गया है! 😉
उन सैंपल का इस्तेमाल करें जिनका इस्तेमाल प्रतिनिधि वर्कलोड के तौर पर किया जा सकता है और देखें कि आपको क्या मिलता है!
2. जटिल कॉल पदानुक्रम से बचें
जहां तक हो सके, अपने कॉल ग्राफ़ को बहुत मुश्किल न बनाएं. जटिल कॉल हैरारकी का इस्तेमाल करने से, परफ़ॉर्मेंस रिग्रेशन को लागू करना आसान होता है. साथ ही, यह समझना मुश्किल होता है कि आपका कोड सही तरीके से क्यों चल रहा है. इससे सुधार करना मुश्किल हो जाता है.
3. गैर-ज़रूरी काम की पहचान करना
पुराने कोड बेस में ऐसा कोड होना आम बात है जिसकी अब ज़रूरत नहीं है. हमारे मामले में, लेगसी और गै़र-ज़रूरी कोड, कॉन्टेंट लोड होने में लगने वाले कुल समय का एक बड़ा हिस्सा हो रहे थे. इसे हटाने का लक्ष्य सबसे कम दिख रहा था.
4. डेटा स्ट्रक्चर का सही तरीके से इस्तेमाल करना
परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए डेटा स्ट्रक्चर का इस्तेमाल करें. साथ ही, इस्तेमाल करने के लिए डेटा स्ट्रक्चर तय करते समय, हर तरह की लागत और कमियों को समझें. यह सिर्फ़ डेटा के स्ट्रक्चर की जटिलता नहीं है, बल्कि लागू होने वाली कार्रवाइयों के समय की जटिलता भी है.
5. जटिल या दोहराई जाने वाली कार्रवाइयों के डुप्लीकेट काम से बचने के लिए, नतीजों को कैश मेमोरी में सेव करें
अगर कार्रवाई को पूरा करना महंगा है, तो अगली बार ज़रूरत पड़ने पर इसके नतीजों को सेव करना बेहतर होता है. अगर कार्रवाई कई बार की जाए, तब भी ऐसा करना सही रहता है—भले ही हर एक समय ज़्यादा महंगा न हो.
6. गै़र-ज़रूरी काम को कुछ समय के लिए रोकें
अगर किसी टास्क के आउटपुट की तुरंत ज़रूरत नहीं है और टास्क का लागू होना अहम पाथ का दायरा बढ़ा रहा है, तो जब इसके आउटपुट की ज़रूरत हो, तब इसे देर से कॉल करें.
7. बड़े इनपुट पर असरदार एल्गोरिदम का इस्तेमाल करना
बड़े इनपुट के लिए, समय जटिल होने वाले एल्गोरिदम अहम हो जाते हैं. इस उदाहरण में हमने इस कैटगरी के बारे में कुछ नहीं लिखा. हालांकि, हमारी अहमियत को बढ़ा-चढ़ाकर नहीं बताया जा सकता.
8. बोनस: अपने पाइपलाइन को बेंचमार्क करें
यह पक्का करने के लिए कि आपका बढ़ता हुआ कोड तेज़ी से बना रहे, व्यवहार को मॉनिटर करना और मानकों से इसकी तुलना करना बेहतर है. इस तरह, रिग्रेशन की पहचान करके उपयोगकर्ता का भरोसा बढ़ाया जा सकता है. साथ ही, लंबे समय तक कामयाबी हासिल की जा सकती है.