परिचय
JavaScript, मेमोरी को अपने-आप मैनेज करने के लिए, गार्बेज कलेक्शन का इस्तेमाल करता है. हालांकि, यह ऐप्लिकेशन में मेमोरी को बेहतर तरीके से मैनेज करने का विकल्प नहीं है. JavaScript ऐप्लिकेशन में मेमोरी से जुड़ी वही समस्याएं आती हैं जो नेटिव ऐप्लिकेशन में आती हैं. जैसे, मेमोरी लीक और ब्लोट. हालांकि, उन्हें गार्बेज कलेक्शन के दौरान होने वाली रुकावटों से भी निपटना पड़ता है. Gmail जैसे बड़े ऐप्लिकेशन को भी उन्हीं समस्याओं का सामना करना पड़ता है जो आपके छोटे ऐप्लिकेशन को करना पड़ता है. Gmail की टीम ने Chrome DevTools का इस्तेमाल करके, मेमोरी से जुड़ी समस्याओं की पहचान कैसे की, उन्हें कैसे अलग किया, और उन्हें कैसे ठीक किया, इस बारे में जानने के लिए आगे पढ़ें.
Google I/O 2013 सेशन
हमने इस कॉन्टेंट को Google I/O 2013 में पेश किया था. नीचे दिया गया वीडियो देखें:
Gmail, हमें एक समस्या आ रही है…
Gmail की टीम को एक गंभीर समस्या का सामना करना पड़ रहा था. कम रैम वाले लैपटॉप और डेस्कटॉप पर, Gmail के टैब कई गीगाबाइट मेमोरी का इस्तेमाल करते हैं. इस वजह से, अक्सर पूरा ब्राउज़र ही बंद हो जाता है. सीपीयू का 100% इस्तेमाल होने, ऐप्लिकेशन के काम न करने, और Chrome के टैब क्रैश होने ("यह काम नहीं कर रहा है, जिम.") की कहानियां. टीम को यह समझ नहीं आ रहा था कि समस्या को ठीक करना तो दूर, उसका पता कैसे लगाया जाए. उन्हें यह नहीं पता था कि समस्या कितनी बड़ी है. साथ ही, उपलब्ध टूल बड़े ऐप्लिकेशन के लिए काम नहीं कर रहे थे. इस टीम ने Chrome की टीमों के साथ मिलकर काम किया. साथ ही, मेमोरी से जुड़ी समस्याओं को हल करने के लिए नई तकनीकें डेवलप कीं, मौजूदा टूल को बेहतर बनाया, और फ़ील्ड से मेमोरी डेटा इकट्ठा करने की सुविधा चालू की. हालांकि, टूल के बारे में जानने से पहले, JavaScript मेमोरी मैनेजमेंट की बुनियादी बातों के बारे में जान लेते हैं.
मेमोरी मैनेज करने से जुड़ी बुनियादी बातें
JavaScript में मेमोरी को बेहतर तरीके से मैनेज करने के लिए, आपको इसके बुनियादी सिद्धांतों को समझना होगा. इस सेक्शन में, प्रिमिटिव टाइप और ऑब्जेक्ट ग्राफ़ के बारे में बताया जाएगा. साथ ही, मेमोरी ब्लोट और JavaScript में मेमोरी लीक की परिभाषाएं दी जाएंगी. JavaScript में मेमोरी को ग्राफ़ के तौर पर समझा जा सकता है. इस वजह से, ग्राफ़ थ्योरी, JavaScript की मेमोरी मैनेज करने और हीप प्रोफ़ाइलर में अहम भूमिका निभाती है.
प्रिमिटिव टाइप
JavaScript में तीन प्रिमिटिव टाइप होते हैं:
- संख्या (उदाहरण के लिए, 4, 3.14159)
- बूलियन (सही या गलत)
- स्ट्रिंग ("नमस्ते")
ये प्रिमिटिव टाइप, किसी अन्य वैल्यू को रेफ़रंस नहीं कर सकते. ऑब्जेक्ट ग्राफ़ में, ये वैल्यू हमेशा लीफ़ या टर्मिनेटिंग नोड होती हैं. इसका मतलब है कि इनमें कभी भी आउटगोइंग एज नहीं होता.
कंटेनर सिर्फ़ एक तरह का होता है: ऑब्जेक्ट. JavaScript में, ऑब्जेक्ट एक असोसिएटिव कलेक्शन होता है. एक ऐसा ऑब्जेक्ट जो खाली नहीं है, वह एक इनर नोड होता है. इसमें अन्य वैल्यू (नोड) के लिए आउटगोइंग एज होते हैं.
अरे के बारे में क्या?
JavaScript में कलेक्शन, असल में एक ऐसा ऑब्जेक्ट होता है जिसमें न्यूमेरिक कुंजियां होती हैं. यह एक आसान तरीका है, क्योंकि JavaScript रनटाइम, कलेक्शन जैसे ऑब्जेक्ट को ऑप्टिमाइज़ करेंगे और उन्हें कलेक्शन के तौर पर दिखाएंगे.
शब्दावली
- वैल्यू - प्रिमिटिव टाइप, ऑब्जेक्ट, कलेक्शन वगैरह का इंस्टेंस.
- वैरिएबल - ऐसा नाम जो किसी वैल्यू को रेफ़र करता है.
- प्रॉपर्टी - किसी ऑब्जेक्ट में मौजूद ऐसा नाम जो किसी वैल्यू को रेफ़र करता है.
ऑब्जेक्ट ग्राफ़
JavaScript में मौजूद सभी वैल्यू, ऑब्जेक्ट ग्राफ़ का हिस्सा होती हैं. ग्राफ़ की शुरुआत रूट से होती है. उदाहरण के लिए, विंडो ऑब्जेक्ट. जीसी रूट के लाइफ़टाइम को मैनेज करना आपके कंट्रोल में नहीं होता. ऐसा इसलिए, क्योंकि इन्हें ब्राउज़र बनाता है और पेज के अनलोड होने पर ये खत्म हो जाते हैं. ग्लोबल वैरिएबल, असल में विंडो की प्रॉपर्टी होते हैं.
कोई वैल्यू, गारबेज कब बन जाती है?
जब रूट से वैल्यू तक का कोई पाथ नहीं होता, तो वैल्यू को गार्बेज माना जाता है. दूसरे शब्दों में, रूट से शुरू करके, स्टैक फ़्रेम में मौजूद सभी ऑब्जेक्ट प्रॉपर्टी और वैरिएबल को पूरी तरह से खोजने पर, कोई वैल्यू नहीं मिलती. इसका मतलब है कि वह वैल्यू अब गारबेज बन चुकी है.
JavaScript में मेमोरी लीक क्या है?
JavaScript में मेमोरी लीक की समस्या आम तौर पर तब होती है, जब कुछ डीओएम नोड, पेज के डीओएम ट्री से ऐक्सेस नहीं किए जा सकते, लेकिन फिर भी उन्हें JavaScript ऑब्जेक्ट से रेफ़रंस किया जाता है. मॉडर्न ब्राउज़र, अनजाने में होने वाले लीक को रोकने के लिए लगातार काम कर रहे हैं. इसके बावजूद, लीक होना अब भी आम बात है. मान लें कि आपने डीओएम ट्री में इस तरह से कोई एलिमेंट जोड़ा है:
email.message = document.createElement("div");
displayList.appendChild(email.message);
इसके बाद, एलिमेंट को डिसप्ले लिस्ट से हटा दिया जाता है:
displayList.removeAllChildren();
जब तक email मौजूद है, तब तक मैसेज से रेफ़रंस किया गया DOM एलिमेंट नहीं हटाया जाएगा. भले ही, वह अब पेज के डीओएम ट्री से अलग हो गया हो.
पेट फूलने की समस्या क्या है?
अगर पेज स्पीड को बेहतर बनाने के लिए, ज़रूरत से ज़्यादा मेमोरी का इस्तेमाल किया जा रहा है, तो इसका मतलब है कि आपका पेज ब्लोटेड है. मेमोरी लीक होने से भी ऐप्लिकेशन का साइज़ बढ़ जाता है. हालांकि, ऐसा जान-बूझकर नहीं किया जाता. ऐसा ऐप्लिकेशन कैश जिसकी कोई साइज़ सीमा नहीं होती, वह आम तौर पर मेमोरी ब्लोट की वजह बनता है. इसके अलावा, आपके पेज पर होस्ट डेटा की वजह से ज़्यादा डेटा लोड हो सकता है. उदाहरण के लिए, इमेज से लोड किया गया पिक्सल डेटा.
गारबेज कलेक्शन क्या है?
गारबेज कलेक्शन, JavaScript में मेमोरी को फिर से हासिल करने का तरीका है. ब्राउज़र यह तय करता है कि ऐसा कब होगा. कलेक्शन के दौरान, आपके पेज पर सभी स्क्रिप्ट का एक्ज़ीक्यूशन रोक दिया जाता है. इस दौरान, जीसी रूट से शुरू होने वाले ऑब्जेक्ट ग्राफ़ के ट्रैवर्सल से लाइव वैल्यू का पता लगाया जाता है. ऐसी सभी वैल्यू जिन्हें ऐक्सेस नहीं किया जा सकता, उन्हें गार्बेज के तौर पर कैटगरी में बांटा जाता है. मेमोरी मैनेजर, ग़ैर-ज़रूरी वैल्यू के लिए इस्तेमाल की गई मेमोरी को फिर से इस्तेमाल के लिए उपलब्ध कराता है.
V8 गारबेज कलेक्टर के बारे में पूरी जानकारी
गार्बेज कलेक्शन की प्रोसेस को बेहतर तरीके से समझने के लिए, आइए V8 गार्बेज कलेक्टर के बारे में ज़्यादा जानें. V8, जनरेशनल कलेक्टर का इस्तेमाल करता है. मेमोरी को दो जनरेशन में बांटा गया है: यंग और ओल्ड. युवा पीढ़ी के बीच, पैसे का लेन-देन तेज़ी से और बार-बार होता है. ओल्ड जनरेशन में, मेमोरी का ऐलोकेशन और कलेक्शन धीमा होता है और कम बार होता है.
जनरेशनल कलेक्टर
V8, दो जनरेशन वाले कलेक्टर का इस्तेमाल करता है. किसी वैल्यू की उम्र, उसे असाइन किए जाने के बाद से असाइन किए गए बाइट की संख्या के तौर पर तय की जाती है. आम तौर पर, किसी वैल्यू की उम्र का अनुमान इस बात से लगाया जाता है कि वह यंग जनरेशन कलेक्शन में कितनी बार बची रही. जब कोई वैल्यू काफ़ी पुरानी हो जाती है, तो उसे पुरानी जनरेशन में भेज दिया जाता है.
आम तौर पर, नई वैल्यू ज़्यादा समय तक नहीं रहतीं. Smalltalk प्रोग्राम की एक स्टडी से पता चला है कि यंग जनरेशन कलेक्शन के बाद, सिर्फ़ 7% वैल्यू ही बची रहती हैं. अलग-अलग रनटाइम पर की गई ऐसी ही स्टडी से पता चला है कि औसतन 90% से 70% नई वैल्यू, कभी भी पुरानी जनरेशन में नहीं जातीं.
युवा पीढ़ी
V8 में यंग जनरेशन हीप को दो स्पेस में बांटा गया है. इन्हें 'from' और 'to' नाम दिया गया है. मेमोरी को 'टू स्पेस' से असाइन किया जाता है. मेमोरी को असाइन करने की प्रोसेस बहुत तेज़ होती है. हालांकि, जब 'टू स्पेस' भर जाता है, तब यंग जनरेशन कलेक्शन ट्रिगर होता है. यंग जनरेशन कलेक्शन, सबसे पहले फ़्रॉम और टू स्पेस को स्वैप करता है. इसके बाद, पुराने टू स्पेस (अब फ़्रॉम स्पेस) को स्कैन किया जाता है और सभी लाइव वैल्यू को टू स्पेस में कॉपी किया जाता है या ओल्ड जनरेशन में भेजा जाता है. आम तौर पर, यंग जनरेशन कलेक्शन में 10 मिलीसेकंड (मि॰से॰) लगते हैं.
आपको यह समझना चाहिए कि आपका ऐप्लिकेशन जो भी मेमोरी ऐलोकेट करता है उससे मेमोरी भरती जाती है और जीसी पॉज़ होने की संभावना बढ़ जाती है. गेम डेवलपर, ध्यान दें: 16 मि॰से॰ का फ़्रेम टाइम (60 फ़्रेम प्रति सेकंड पाने के लिए ज़रूरी) पक्का करने के लिए, आपके ऐप्लिकेशन को शून्य ऐलोकेशन करना होगा. ऐसा इसलिए, क्योंकि एक यंग जनरेशन कलेक्शन, फ़्रेम टाइम का ज़्यादातर हिस्सा इस्तेमाल कर लेगा.
पुरानी जनरेशन
V8 में पुरानी जनरेशन का हीप, कलेक्शन के लिए मार्क-कॉम्पैक्ट एल्गोरिदम का इस्तेमाल करता है. जब किसी वैल्यू को यंग जनरेशन से ओल्ड जनरेशन में ट्रांसफ़र किया जाता है, तब ओल्ड जनरेशन के लिए मेमोरी का ऐलोकेशन होता है. जब भी ओल्ड जनरेशन कलेक्शन होता है, तब यंग जनरेशन कलेक्शन भी होता है. आपका ऐप्लिकेशन कुछ सेकंड के लिए रुक जाएगा. आम तौर पर, यह स्वीकार्य है, क्योंकि पुरानी जनरेशन के कलेक्शन बहुत कम होते हैं.
V8 GC की खास जानकारी
गार्बेज कलेक्शन के साथ अपने-आप मेमोरी मैनेज होने की सुविधा, डेवलपर की प्रॉडक्टिविटी के लिए बहुत अच्छी है. हालांकि, हर बार कोई वैल्यू असाइन करने पर, गार्बेज कलेक्शन के रुकने की संभावना बढ़ जाती है. गार्बेज कलेक्शन के रुकने से, आपके ऐप्लिकेशन में जैंक आ सकता है. इससे ऐप्लिकेशन का अनुभव खराब हो सकता है. अब आपको पता है कि JavaScript, मेमोरी को कैसे मैनेज करता है. इसलिए, अपने ऐप्लिकेशन के लिए सही विकल्प चुनें.
Gmail से जुड़ी समस्याएं ठीक करना
पिछले साल, Chrome DevTools में कई सुविधाएं जोड़ी गईं और गड़बड़ियां ठीक की गईं. इससे यह पहले से ज़्यादा बेहतर हो गया है. इसके अलावा, ब्राउज़र ने performance.memory एपीआई में एक अहम बदलाव किया है. इससे Gmail और अन्य ऐप्लिकेशन, फ़ील्ड से मेमोरी के आंकड़े इकट्ठा कर सकते हैं. इन शानदार टूल की मदद से, जो काम पहले नामुमकिन लगता था वह अब अपराधियों को पकड़ने का एक रोमांचक गेम बन गया.
टूल और तकनीक
फ़ील्ड डेटा और performance.memory API
Chrome 22 से, performance.memory API डिफ़ॉल्ट रूप से चालू है. Gmail जैसे लंबे समय से इस्तेमाल किए जा रहे ऐप्लिकेशन के लिए, असली उपयोगकर्ताओं का डेटा बहुत अहम होता है. इस जानकारी से हमें Gmail के जानकार उपयोगकर्ताओं और सामान्य उपयोगकर्ताओं के बीच अंतर करने में मदद मिलती है. जानकार उपयोगकर्ता, Gmail पर हर दिन 8 से 16 घंटे बिताते हैं और उन्हें हर दिन सैकड़ों ईमेल मिलते हैं. वहीं, सामान्य उपयोगकर्ता, Gmail पर हर दिन कुछ मिनट बिताते हैं और उन्हें हर हफ़्ते करीब एक दर्जन ईमेल मिलते हैं.
यह एपीआई, तीन तरह का डेटा दिखाता है:
- jsHeapSizeLimit - मेमोरी की वह मात्रा (बाइट में) जिस तक JavaScript हीप सीमित है.
- totalJSHeapSize - मेमोरी की वह मात्रा (बाइट में) जो JavaScript हीप ने खाली जगह के साथ असाइन की है.
- usedJSHeapSize - फ़िलहाल इस्तेमाल की जा रही मेमोरी (बाइट में).
एक बात का ध्यान रखें कि एपीआई, Chrome की पूरी प्रोसेस के लिए मेमोरी वैल्यू दिखाता है. हालांकि, यह डिफ़ॉल्ट मोड नहीं है, लेकिन कुछ मामलों में Chrome, रेंडर करने की एक ही प्रोसेस में कई टैब खोल सकता है. इसका मतलब है कि performance.memory से मिलने वाली वैल्यू में, आपके ऐप्लिकेशन वाले टैब के अलावा, अन्य ब्राउज़र टैब का मेमोरी फ़ुटप्रिंट भी शामिल हो सकता है.
बड़े पैमाने पर मेमोरी को मापना
Gmail ने अपनी JavaScript को इस तरह से तैयार किया है कि वह performance.memory एपीआई का इस्तेमाल करके, हर 30 मिनट में एक बार मेमोरी की जानकारी इकट्ठा कर सके. कई Gmail उपयोगकर्ता, ऐप्लिकेशन को कई दिनों तक बंद नहीं करते. इसलिए, टीम समय के साथ मेमोरी के इस्तेमाल में हुई बढ़ोतरी के साथ-साथ, मेमोरी फ़ुटप्रिंट के कुल आंकड़ों को ट्रैक कर पाई. Gmail में मेमोरी की जानकारी इकट्ठा करने के लिए, उपयोगकर्ताओं के रैंडम सैंपल का इस्तेमाल किया गया. कुछ ही दिनों में, टीम के पास इतना डेटा इकट्ठा हो गया कि वह यह समझ सके कि मेमोरी की समस्याएं, आम उपयोगकर्ताओं के बीच कितनी आम थीं. उन्होंने एक बेसलाइन सेट की और आने वाले डेटा की स्ट्रीम का इस्तेमाल करके, मेमोरी की खपत को कम करने के लक्ष्य की दिशा में हुई प्रोग्रेस को ट्रैक किया. इस डेटा का इस्तेमाल, मेमोरी रिग्रेशन का पता लगाने के लिए भी किया जाएगा.
ट्रैकिंग के अलावा, फ़ील्ड मेज़रमेंट से मेमोरी फ़ुटप्रिंट और ऐप्लिकेशन की परफ़ॉर्मेंस के बीच के संबंध के बारे में भी अहम जानकारी मिलती है. आम तौर पर माना जाता है कि "ज़्यादा मेमोरी से बेहतर परफ़ॉर्मेंस मिलती है". हालांकि, Gmail की टीम ने पाया कि मेमोरी फ़ुटप्रिंट जितना बड़ा होता है, Gmail की सामान्य कार्रवाइयों में उतना ही ज़्यादा इंतज़ार करना पड़ता है. इस जानकारी के बाद, वे मेमोरी के इस्तेमाल को कम करने के लिए पहले से ज़्यादा प्रेरित हुए.
DevTools की टाइमलाइन की मदद से, मेमोरी से जुड़ी समस्या की पहचान करना
परफ़ॉर्मेंस से जुड़ी किसी भी समस्या को हल करने का पहला चरण यह साबित करना है कि समस्या मौजूद है. इसके लिए, एक ऐसा टेस्ट बनाएं जिसे फिर से किया जा सके और समस्या का बेसलाइन मेज़रमेंट लें. अगर आपके पास समस्या को दोहराने का कोई तरीका नहीं है, तो समस्या को सही तरीके से नहीं समझा जा सकता. बेसलाइन मेज़रमेंट के बिना, यह नहीं पता चलता कि आपने परफ़ॉर्मेंस को कितना बेहतर बनाया है.
DevTools का टाइमलाइन पैनल, समस्या की मौजूदगी साबित करने के लिए सबसे सही है. इससे आपको पूरी जानकारी मिलती है कि आपके वेब ऐप्लिकेशन या पेज को लोड होने और उससे इंटरैक्ट करने में कितना समय लगता है. सभी इवेंट को टाइमलाइन पर दिखाया जाता है. इनमें रिसॉर्स लोड करने से लेकर JavaScript को पार्स करने, स्टाइल का हिसाब लगाने, गार्बेज कलेक्शन को रोकने, और फिर से पेंट करने तक के इवेंट शामिल हैं. मेमोरी से जुड़ी समस्याओं की जांच करने के लिए, टाइमलाइन पैनल में मेमोरी मोड भी होता है. यह मोड, असाइन की गई कुल मेमोरी, डीओएम नोड की संख्या, विंडो ऑब्जेक्ट की संख्या, और असाइन किए गए इवेंट लिसनर की संख्या को ट्रैक करता है.
समस्या की मौजूदगी साबित करना
सबसे पहले, उन कार्रवाइयों के क्रम की पहचान करें जिनसे आपको लगता है कि मेमोरी लीक हो रही है. टाइमलाइन को रिकॉर्ड करना शुरू करें और कार्रवाइयों का क्रम पूरा करें. सबसे नीचे मौजूद ट्रैश कैन बटन का इस्तेमाल करके, मेमोरी को पूरी तरह से खाली करें. अगर कुछ बार दोहराने के बाद, आपको सॉटूथ के आकार का ग्राफ़ दिखता है, तो इसका मतलब है कि आपने कम समय तक रहने वाले कई ऑब्जेक्ट असाइन किए हैं. हालांकि, अगर कार्रवाइयों के क्रम से कोई मेमोरी सेव नहीं होने की उम्मीद है और डीओएम नोड की संख्या, उस बेसलाइन पर वापस नहीं आती जहां से आपने शुरू किया था, तो आपको शक हो सकता है कि मेमोरी लीक हो रही है.
समस्या की पुष्टि होने के बाद, DevTools के हीप प्रोफ़ाइलर की मदद से समस्या की वजह का पता लगाया जा सकता है.
DevTools के हीप प्रोफ़ाइलर की मदद से मेमोरी लीक का पता लगाना
प्रोफ़ाइलर पैनल में, सीपीयू प्रोफ़ाइलर और हीप प्रोफ़ाइलर, दोनों मौजूद होते हैं. हीप प्रोफ़ाइलिंग, ऑब्जेक्ट ग्राफ़ का स्नैपशॉट लेकर काम करती है. स्नैपशॉट लेने से पहले, नई और पुरानी दोनों जनरेशन का गारबेज कलेक्शन किया जाता है. दूसरे शब्दों में, आपको सिर्फ़ वे वैल्यू दिखेंगी जो स्नैपशॉट लेते समय मौजूद थीं.
हीप प्रोफ़ाइलर में कई सुविधाएं हैं. इस लेख में उन सभी के बारे में पूरी जानकारी नहीं दी जा सकती. हालांकि, Chrome Developers की साइट पर ज़्यादा जानकारी वाला दस्तावेज़ देखा जा सकता है. हम यहां हीप ऐलोकेशन प्रोफ़ाइलर पर फ़ोकस करेंगे.
हीप ऐलोकेशन प्रोफ़ाइलर का इस्तेमाल करना
हीप ऐलोकेशन प्रोफ़ाइलर, हीप प्रोफ़ाइलर के स्नैपशॉट की पूरी जानकारी को टाइमलाइन पैनल के इंक्रीमेंटल अपडेट और ट्रैकिंग के साथ जोड़ता है. प्रोफ़ाइल पैनल खोलें, हीप ऐलोकेशन रिकॉर्ड करें प्रोफ़ाइल शुरू करें, कार्रवाइयों का क्रम पूरा करें, और फिर विश्लेषण के लिए रिकॉर्डिंग बंद करें. एलोकेशन प्रोफ़ाइलर, रिकॉर्डिंग के दौरान समय-समय पर हीप स्नैपशॉट लेता है. यह हर 50 मि॰से॰ में स्नैपशॉट लेता है! साथ ही, रिकॉर्डिंग के आखिर में एक फ़ाइनल स्नैपशॉट लेता है.
सबसे ऊपर मौजूद बार से पता चलता है कि हीप में नए ऑब्जेक्ट कब मिले. हर बार की ऊंचाई, हाल ही में असाइन किए गए ऑब्जेक्ट के साइज़ के हिसाब से होती है. साथ ही, बार के रंग से पता चलता है कि वे ऑब्जेक्ट अब भी फ़ाइनल हीप स्नैपशॉट में लाइव हैं या नहीं: नीले रंग के बार उन ऑब्जेक्ट को दिखाते हैं जो टाइमलाइन के आखिर में अब भी लाइव हैं. वहीं, स्लेटी रंग के बार उन ऑब्जेक्ट को दिखाते हैं जिन्हें टाइमलाइन के दौरान असाइन किया गया था, लेकिन अब उन्हें गार्बेज कलेक्शन में डाल दिया गया है.
ऊपर दिए गए उदाहरण में, कोई कार्रवाई 10 बार की गई. सैंपल प्रोग्राम में पांच ऑब्जेक्ट कैश मेमोरी में सेव होते हैं. इसलिए, आखिरी पांच नीले बार दिखने की उम्मीद है. हालांकि, सबसे बाईं ओर मौजूद नीला बार, संभावित समस्या की ओर इशारा करता है. इसके बाद, ऊपर दी गई टाइमलाइन में मौजूद स्लाइडर का इस्तेमाल करके, उस स्नैपशॉट को ज़ूम इन किया जा सकता है. साथ ही, उन ऑब्जेक्ट को देखा जा सकता है जिन्हें हाल ही में उस पॉइंट पर असाइन किया गया था. हीप में किसी खास ऑब्जेक्ट पर क्लिक करने से, हीप स्नैपशॉट के सबसे निचले हिस्से में उसका रिटेनिंग ट्री दिखेगा. ऑब्जेक्ट के रिटेनिंग पाथ की जांच करने से, आपको यह समझने में मदद मिलेगी कि ऑब्जेक्ट को क्यों इकट्ठा नहीं किया गया. साथ ही, ग़ैर-ज़रूरी रेफ़रंस को हटाने के लिए, कोड में ज़रूरी बदलाव किए जा सकते हैं.
Gmail में स्टोरेज की समस्या को हल करना
ऊपर बताए गए टूल और तकनीकों का इस्तेमाल करके, Gmail की टीम ने बग की कुछ कैटगरी की पहचान की: अनबाउंड कैश मेमोरी, कॉलबैक के लगातार बढ़ते कलेक्शन, और इवेंट लिसनर. कॉलबैक के कलेक्शन में, किसी ऐसी चीज़ के होने का इंतज़ार किया जा रहा था जो असल में कभी नहीं होती. वहीं, इवेंट लिसनर अनजाने में अपने टारगेट को बनाए रखते हैं. इन समस्याओं को ठीक करने से, Gmail में मेमोरी के इस्तेमाल में काफ़ी कमी आई. 99% उपयोगकर्ताओं ने पहले के मुकाबले 80% कम मेमोरी का इस्तेमाल किया. साथ ही, मीडियन उपयोगकर्ताओं की मेमोरी की खपत में करीब 50% की गिरावट आई.
Gmail में कम मेमोरी का इस्तेमाल होने की वजह से, जीसी पॉज़ लेटेंसी कम हो गई. इससे उपयोगकर्ताओं को बेहतर अनुभव मिला.
यह भी ध्यान देने वाली बात है कि Gmail की टीम ने मेमोरी के इस्तेमाल से जुड़े आंकड़े इकट्ठा किए. इससे उन्हें Chrome में गार्बेज कलेक्शन रिग्रेशन का पता चला. खास तौर पर, फ़्रैगमेंटेशन से जुड़ी दो गड़बड़ियों का पता तब चला, जब Gmail के मेमोरी डेटा में, मेमोरी के बंटवारे की कुल मेमोरी और लाइव मेमोरी के बीच का अंतर काफ़ी ज़्यादा दिखने लगा.
कॉल-टू-ऐक्शन
खुद से ये सवाल पूछें:
- मेरा ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल कर रहा है? ऐसा हो सकता है कि आपका ऐप्लिकेशन बहुत ज़्यादा मेमोरी का इस्तेमाल कर रहा हो. इससे ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ता है. यह जानना मुश्किल है कि सही संख्या क्या है. हालांकि, यह पक्का करें कि आपके पेज पर इस्तेमाल की जा रही किसी भी अतिरिक्त कैश मेमोरी का, परफ़ॉर्मेंस पर असर पड़ रहा हो.
- क्या मेरे पेज पर मौजूद जानकारी लीक नहीं हुई है? अगर आपके पेज पर मेमोरी लीक की समस्या है, तो इससे आपके पेज की परफ़ॉर्मेंस पर असर पड़ सकता है. साथ ही, अन्य टैब पर भी असर पड़ सकता है. ऑब्जेक्ट ट्रैकर का इस्तेमाल करके, लीक की सटीक जानकारी पाएं.
- मेरा पेज कितनी बार जीसी हो रहा है? Chrome डेवलपर टूल में टाइमलाइन पैनल का इस्तेमाल करके, जीसी के किसी भी पॉज़ को देखा जा सकता है. अगर आपके पेज पर बार-बार जीसी हो रहा है, तो हो सकता है कि आप बार-बार मेमोरी असाइन कर रहे हों. इससे आपकी यंग जनरेशन मेमोरी खत्म हो रही है.
नतीजा
हमने इस प्रोजेक्ट की शुरुआत एक संकट के समय की थी. JavaScript और खास तौर पर V8 में, मेमोरी मैनेज करने से जुड़ी बुनियादी बातों के बारे में बताया गया है. आपने टूल इस्तेमाल करने का तरीका सीखा. इनमें Chrome के नए बिल्ड में उपलब्ध, ऑब्जेक्ट ट्रैकर की नई सुविधा भी शामिल है. इस जानकारी की मदद से, Gmail की टीम ने मेमोरी के इस्तेमाल से जुड़ी समस्या को हल किया और परफ़ॉर्मेंस को बेहतर बनाया. अपने वेब ऐप्लिकेशन के साथ भी ऐसा किया जा सकता है!