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