परिचय
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 ऑब्जेक्ट से किया जाता है. मॉडर्न ब्राउज़र, गलती से जानकारी लीक होने की संभावना को कम कर रहे हैं. हालांकि, यह अब भी उतना आसान है जितना लोग सोचते हैं. मान लें कि आपने DOM ट्री में इस तरह एलिमेंट जोड़ा है:
email.message = document.createElement("div");
displayList.appendChild(email.message);
बाद में, डिसप्ले सूची से एलिमेंट को हटाया जाता है:
displayList.removeAllChildren();
जब तक email मौजूद है, तब तक मैसेज से रेफ़र किए गए DOM एलिमेंट को नहीं हटाया जाएगा. भले ही, वह अब पेज के DOM ट्री से अलग हो गया हो.
ब्लोट क्या है?
जब पेज की स्पीड को बेहतर बनाने के लिए ज़रूरत से ज़्यादा मेमोरी का इस्तेमाल किया जाता है, तो आपका पेज बड़ा हो जाता है. मेमोरी लीक की वजह से भी, डिवाइस का स्टोरेज भर जाता है. हालांकि, ऐसा डिज़ाइन के हिसाब से नहीं होता. ऐप्लिकेशन कैश का साइज़ तय न होना, मेमोरी में फ़ाइलों के साइज़ बढ़ने की एक आम वजह है. साथ ही, होस्ट डेटा की वजह से भी आपका पेज बड़ा हो सकता है. उदाहरण के लिए, इमेज से लोड किया गया पिक्सल डेटा.
गार्बेज कलेक्शन क्या है?
गार्बेज कलेक्शन की मदद से, JavaScript में मेमोरी वापस ली जाती है. ब्राउज़र यह तय करता है कि ऐसा कब होगा. कलेक्शन के दौरान, आपके पेज पर सभी स्क्रिप्ट निष्पादन निलंबित कर दिया जाता है. इस दौरान, लाइव वैल्यू का पता लगाने के लिए, ऑब्जेक्ट ग्राफ़ को ट्रैवर्स किया जाता है. यह ट्रैवर्स, GC रूट से शुरू होता है. जिन वैल्यू को पहुंचाया नहीं जा सकता उन्हें ग़ैर-ज़रूरी वैल्यू के तौर पर मार्क किया जाता है. मेमोरी मैनेजर, ग़ैर-ज़रूरी वैल्यू के लिए मेमोरी वापस ले लेता है.
V8 गारबेज कलेक्टर के बारे में ज़्यादा जानकारी
ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस को बेहतर तरीके से समझने के लिए, V8 ग़ैर-ज़रूरी डेटा हटाने वाले टूल के बारे में ज़्यादा जानें. V8, जनरेशनल कलेक्टर का इस्तेमाल करता है. मेमोरी को दो पीढ़ियों में बांटा गया है: युवा और बुज़ुर्ग. युवा पीढ़ी में, डेटा का ऐलोकेशन और कलेक्शन तेज़ी से और बार-बार होता है. पुरानी पीढ़ी में, एलोकेशन और कलेक्शन की प्रोसेस धीमी और कम होती है.
Generational Collector
V8, दो जनरेशन वाले कलेक्टर का इस्तेमाल करता है. किसी वैल्यू की उम्र, उसे असाइन किए जाने के बाद से असाइन किए गए बाइट की संख्या के तौर पर तय की जाती है. आम तौर पर, किसी वैल्यू की उम्र का अनुमान, उसमें शामिल उन नए कलेक्शन की संख्या से लगाया जाता है जो अब भी मौजूद हैं. किसी वैल्यू के पुराने होने के बाद, उसे पुरानी जनरेशन में शामिल कर लिया जाता है.
आम तौर पर, हाल ही में असाइन की गई वैल्यू लंबे समय तक नहीं रहतीं. Smalltalk प्रोग्राम के एक अध्ययन से पता चला है कि नई जनरेशन के कलेक्शन के बाद, सिर्फ़ 7% वैल्यू बचती हैं. अलग-अलग रनटाइम पर की गई ऐसी ही स्टडी से पता चला है कि हाल ही में असाइन की गई 90% से 70% वैल्यू, पुरानी जनरेशन में कभी भी शामिल नहीं होती हैं.
यंग जनरेशन
V8 में, यंग जनरेशन हीप को दो स्पेस में बांटा गया है. इनका नाम from और to है. मेमोरी, स्पेस से असाइन की जाती है. स्पेस में जगह खाली होने तक, एलोकेशन बहुत तेज़ी से होता है. इसके बाद, नई जनरेशन का कलेक्शन ट्रिगर होता है. नई जनरेशन का कलेक्शन, पहले 'से' और 'में' स्पेस को स्वैप करता है. इसके बाद, पुराने 'में' स्पेस (अब 'से' स्पेस) को स्कैन किया जाता है. साथ ही, सभी लाइव वैल्यू को 'में' स्पेस में कॉपी किया जाता है या पुरानी जनरेशन में रखा जाता है. आम तौर पर, नई जनरेशन के डेटा को इकट्ठा करने में 10 मिलीसेकंड (ms) लगेंगे.
आपको यह समझना चाहिए कि आपके ऐप्लिकेशन के हर ऐलोकेशन से, स्टोरेज की कमी होती है और जीसी (गेन्स कैश) रोकना पड़ता है. गेम डेवलपर, ध्यान दें: 16 मि॰से॰ का फ़्रेम टाइम (60 फ़्रेम प्रति सेकंड पाने के लिए ज़रूरी) पक्का करने के लिए, आपके ऐप्लिकेशन को कोई भी ऐलोकेशन नहीं देना चाहिए. इसकी वजह यह है कि एक ही जनरेशन का कलेक्शन, ज़्यादातर फ़्रेम टाइम खर्च कर देगा.
पुरानी जनरेशन
V8 में पुरानी जनरेशन वाली ढेर, कलेक्शन के लिए मार्क-कॉम्पैक्ट एल्गोरिदम का इस्तेमाल करती है. जब भी किसी वैल्यू को नई जनरेशन से पुरानी जनरेशन में ट्रांसफ़र किया जाता है, तब पुरानी जनरेशन के लिए एलोकेशन तय किए जाते हैं. जब भी पुरानी जनरेशन का कलेक्शन होता है, तो नई जनरेशन का कलेक्शन भी होता है. आपका ऐप्लिकेशन कुछ सेकंड के लिए रुक जाएगा. आम तौर पर, ऐसा किया जा सकता है, क्योंकि पुराने कलेक्शन अक्सर नहीं मिलते.
V8 GC की खास जानकारी
ग़ैर-ज़रूरी डेटा हटाने की सुविधा के साथ, अपने-आप मेमोरी मैनेज होना, डेवलपर की प्रॉडक्टिविटी के लिए बहुत अच्छा है. हालांकि, हर बार कोई वैल्यू असाइन करने पर, ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस रुक जाती है. ग़ैर-ज़रूरी डेटा इकट्ठा करने की प्रोसेस के रुकने पर, ऐप्लिकेशन में रुकावट आ सकती है. अब आपको पता है कि JavaScript, मेमोरी को कैसे मैनेज करता है. इसलिए, अपने ऐप्लिकेशन के लिए सही विकल्प चुने जा सकते हैं.
Gmail को ठीक करना
पिछले एक साल में, Chrome DevTools में कई सुविधाएं और गड़बड़ियों को ठीक किया गया है. इससे, यह टूल पहले से ज़्यादा बेहतर हो गया है. इसके अलावा, ब्राउज़र ने खुद performance.memory API में एक अहम बदलाव किया है. इससे 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 में, हर 30 मिनट में मेमोरी की जानकारी इकट्ठा करने के लिए, performance.memory API का इस्तेमाल करने की सुविधा जोड़ी है. Gmail के कई उपयोगकर्ता, ऐप्लिकेशन को कई दिनों तक चालू रखते हैं. इसलिए, टीम समय के साथ मेमोरी में हुई बढ़ोतरी के साथ-साथ, मेमोरी के इस्तेमाल से जुड़े आंकड़े भी ट्रैक कर पाई. उपयोगकर्ताओं के किसी रैंडम सैंपल से मेमोरी की जानकारी इकट्ठा करने के लिए, Gmail में टूल जोड़ने के कुछ दिनों के अंदर ही टीम के पास इतना डेटा इकट्ठा हो गया था कि यह समझा जा सके कि औसत उपयोगकर्ताओं में मेमोरी से जुड़ी समस्याएं कितनी आम हैं. उन्होंने एक बेसलाइन सेट की और मेमोरी खर्च को कम करने के लक्ष्य की प्रोग्रेस को ट्रैक करने के लिए, आने वाले डेटा की स्ट्रीम का इस्तेमाल किया. आखिर में, इस डेटा का इस्तेमाल किसी भी मेमोरी रिग्रेशन को पकड़ने के लिए भी किया जाएगा.
ट्रैकिंग के अलावा, फ़ील्ड मेज़रमेंट से मेमोरी फ़ुटप्रिंट और ऐप्लिकेशन की परफ़ॉर्मेंस के बीच के संबंध के बारे में अहम जानकारी भी मिलती है. आम तौर पर यह माना जाता है कि "ज़्यादा मेमोरी से बेहतर परफ़ॉर्मेंस मिलती है". हालांकि, Gmail की टीम को पता चला है कि मेमोरी फ़ुटप्रिंट जितना बड़ा होगा, Gmail की सामान्य कार्रवाइयों में उतनी ही ज़्यादा देरी होगी. इस जानकारी के बाद, वे मेमोरी के इस्तेमाल को कम करने के लिए पहले से ज़्यादा उत्साहित थे.
DevTools टाइमलाइन की मदद से, मेमोरी से जुड़ी समस्या की पहचान करना
परफ़ॉर्मेंस से जुड़ी किसी भी समस्या को हल करने का पहला चरण यह साबित करना है कि समस्या मौजूद है. इसके बाद, दोबारा चलाया जा सकने वाला टेस्ट बनाएं और समस्या का बेसलाइन मेज़रमेंट करें. बार-बार होने वाली समस्या को ठीक करने के लिए, किसी प्रोग्राम की ज़रूरत होती है. बेसलाइन मेज़रमेंट के बिना, यह पता नहीं चलता कि आपने परफ़ॉर्मेंस को कितना बेहतर बनाया है.
DevTools टाइमलाइन पैनल, यह साबित करने के लिए सबसे सही विकल्प है कि समस्या मौजूद है. इससे यह पूरी जानकारी मिलती है कि आपके वेब ऐप्लिकेशन या पेज को लोड करने और उससे इंटरैक्ट करने में कितना समय बीतता है. रिसॉर्स लोड करने से लेकर JavaScript को पार्स करने, स्टाइल का हिसाब लगाने, गै़रबेज कलेक्शन के लिए रोक लगाने, और फिर से पेंट करने तक के सभी इवेंट, टाइमलाइन पर प्लॉट किए जाते हैं. मेमोरी से जुड़ी समस्याओं की जांच करने के लिए, टाइमलाइन पैनल में मेमोरी मोड भी होता है. यह मोड, एलोकेट की गई कुल मेमोरी, डीओएम नोड की संख्या, विंडो ऑब्जेक्ट की संख्या, और एलोकेट किए गए इवेंट लिसनर की संख्या को ट्रैक करता है.
यह साबित करना कि कोई समस्या मौजूद है
सबसे पहले, उन कार्रवाइयों के क्रम की पहचान करें जिनकी वजह से आपको लगता है कि मेमोरी लीक हो रही है. टाइमलाइन रिकॉर्ड करना शुरू करें और कार्रवाइयों का क्रम पूरा करें. ट्रैश कलेक्शन को तुरंत शुरू करने के लिए, सबसे नीचे मौजूद ट्रैश कैन बटन का इस्तेमाल करें. अगर कुछ बार दोहराए जाने के बाद, आपको सॉटूथ आकार का ग्राफ़ दिखता है, तो इसका मतलब है कि आपने बहुत सारे ऐसे ऑब्जेक्ट असाइन किए हैं जो थोड़े समय के लिए ही मौजूद रहते हैं. हालांकि, अगर कार्रवाइयों के क्रम से कोई मेमोरी सेव नहीं होती है और डीओएम नोड की संख्या, शुरुआती बेसलाइन पर वापस नहीं आती है, तो आपको संदेह करने की अच्छी वजह है कि कोई लीक है.
इस बात की पुष्टि करने के बाद कि समस्या मौजूद है, DevTools के Heap Profiler से समस्या के सोर्स की पहचान करने में मदद मिल सकती है.
DevTools के हीप प्रोफ़ाइलर की मदद से, मेमोरी लीक ढूंढना
प्रोफ़ाइलर पैनल में, सीपीयू प्रोफ़ाइलर और हीप प्रोफ़ाइलर, दोनों की सुविधा मिलती है. ढेर की प्रोफ़ाइलिंग, ऑब्जेक्ट ग्राफ़ का स्नैपशॉट लेकर काम करती है. स्नैपशॉट लेने से पहले, नई और पुरानी दोनों पीढ़ियों का कचरा इकट्ठा किया जाता है. दूसरे शब्दों में, आपको सिर्फ़ वे वैल्यू दिखेंगी जो स्नैपशॉट लेने के समय मौजूद थीं.
इस लेख में, हीप प्रोफ़ाइलर की सभी सुविधाओं के बारे में पूरी जानकारी नहीं दी जा सकती. हालांकि, Chrome Developers की साइट पर ज़्यादा जानकारी वाला दस्तावेज़ देखा जा सकता है. हम यहां हीप ऐलोकेशन प्रोफ़ाइलर पर फ़ोकस करेंगे.
हीप ऐलोकेशन प्रोफ़ाइलर का इस्तेमाल करना
Heap Allocation profiler, Heap Profiler के स्नैपशॉट की ज़्यादा जानकारी को टाइमलाइन पैनल के इंक्रीमेंटल अपडेट और ट्रैकिंग के साथ जोड़ता है. प्रोफ़ाइल पैनल खोलें, हीप ऐलोकेशन रिकॉर्ड करें प्रोफ़ाइल शुरू करें, कार्रवाइयों का क्रम पूरा करें, और फिर विश्लेषण के लिए रिकॉर्डिंग बंद करें. ऐलोकेशन प्रोफ़ाइलर, रिकॉर्डिंग के दौरान समय-समय पर (हर 50 मिलीसेकंड के हिसाब से!) और रिकॉर्डिंग के आखिर में एक फ़ाइनल स्नैपशॉट लेता है.
सबसे ऊपर मौजूद बार से पता चलता है कि ढेर में नए ऑब्जेक्ट कब मिलते हैं. हर बार की ऊंचाई, हाल ही में एलोकेट किए गए ऑब्जेक्ट के साइज़ से मेल खाती है. साथ ही, बार के रंग से पता चलता है कि वे ऑब्जेक्ट अब भी फ़ाइनल हीप स्नैपशॉट में मौजूद हैं या नहीं: नीले रंग के बार से उन ऑब्जेक्ट के बारे में पता चलता है जो टाइमलाइन के आखिर में भी लाइव हैं. वहीं, स्लेटी रंग के बार से उन ऑब्जेक्ट के बारे में पता चलता है जिन्हें टाइमलाइन के दौरान एलोकेट किया गया था, लेकिन अब उन्हें गै़रबेज इकट्ठा कर लिया गया है.
ऊपर दिए गए उदाहरण में, कोई कार्रवाई 10 बार की गई. सैंपल प्रोग्राम में पांच ऑब्जेक्ट कैश मेमोरी में सेव किए जाते हैं. इसलिए, आखिर में पांच नीले बार दिख सकते हैं. हालांकि, सबसे बाईं ओर मौजूद नीले रंग का बार, किसी संभावित समस्या के बारे में बताता है. इसके बाद, ऊपर दी गई टाइमलाइन में स्लाइडर का इस्तेमाल करके, उस खास स्नैपशॉट पर ज़ूम इन किया जा सकता है. साथ ही, उस समय हाल ही में एलोकेट किए गए ऑब्जेक्ट देखे जा सकते हैं. ढेर में किसी खास ऑब्जेक्ट पर क्लिक करने से, ढेर के स्नैपशॉट के सबसे नीचे हिस्से में उसका रिटेनिंग ट्री दिखेगा. ऑब्जेक्ट के रिटेनिंग पाथ की जांच करने से, आपको यह समझने के लिए ज़रूरी जानकारी मिल सकती है कि ऑब्जेक्ट को इकट्ठा क्यों नहीं किया गया. साथ ही, ग़ैर-ज़रूरी रेफ़रंस को हटाने के लिए, कोड में ज़रूरी बदलाव किए जा सकते हैं.
Gmail में स्टोरेज की समस्या हल करना
ऊपर बताए गए टूल और तकनीकों का इस्तेमाल करके, Gmail की टीम को गड़बड़ियों की कुछ कैटगरी की पहचान करने में मदद मिली: अनलिमिटेड कैश मेमोरी, कॉलबैक के अनलिमिटेड ऐरे, जो किसी ऐसी चीज़ के होने का इंतज़ार कर रहे हैं जो कभी नहीं होती, और इवेंट लिसनर, जो अनजाने में अपने टारगेट को बनाए रखते हैं. इन समस्याओं को ठीक करने से, Gmail के लिए इस्तेमाल होने वाली मेमोरी का कुल इस्तेमाल काफ़ी कम हो गया. 99% उपयोगकर्ताओं ने पहले के मुकाबले 80% कम मेमोरी का इस्तेमाल किया. साथ ही, औसत उपयोगकर्ताओं की मेमोरी खपत में करीब 50% की कमी आई.
Gmail ने कम मेमोरी का इस्तेमाल किया, इसलिए GC के रुकने की अवधि कम हो गई. इससे उपयोगकर्ताओं को बेहतर अनुभव मिला.
यह भी ध्यान देने वाली बात है कि Gmail की टीम ने मेमोरी के इस्तेमाल के आंकड़े इकट्ठा किए. इससे उन्हें Chrome में, ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस में हुई गिरावट का पता चला. खास तौर पर, Gmail के मेमोरी डेटा में कुल मेमोरी और लाइव मेमोरी के बीच का अंतर काफ़ी बढ़ने पर, फ़्रैगमेंटेशन से जुड़े दो बग का पता चला.
कॉल-टू-ऐक्शन
खुद से ये सवाल पूछें:
- मेरा ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल कर रहा है? ऐसा हो सकता है कि आपने बहुत ज़्यादा मेमोरी का इस्तेमाल किया हो. आम तौर पर, ऐसा माना जाता है कि ज़्यादा मेमोरी का इस्तेमाल करने से ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ता है. यह पता लगाना मुश्किल है कि सही संख्या क्या है. हालांकि, यह पक्का करें कि आपके पेज पर इस्तेमाल की जा रही अतिरिक्त कैश मेमोरी से, परफ़ॉर्मेंस पर असर पड़ता हो.
- क्या मेरे पेज से कोई डेटा लीक नहीं हुआ है? अगर आपके पेज में मेमोरी लीक है, तो इससे आपके पेज की परफ़ॉर्मेंस पर ही नहीं, बल्कि दूसरे टैब पर भी असर पड़ सकता है. किसी भी तरह के लीक का पता लगाने के लिए, ऑब्जेक्ट ट्रैकर का इस्तेमाल करें.
- मेरा पेज कितनी बार जीसी हो रहा है? Chrome डेवलपर टूल में टाइमलाइन पैनल का इस्तेमाल करके, किसी भी जीसी के रुकने की जानकारी देखी जा सकती है. अगर आपका पेज बार-बार जीसी कर रहा है, तो हो सकता है कि आपने ज़रूरत से ज़्यादा मेमोरी ऐलोकेट की हो.
नतीजा
हमने मुश्किल समय में शुरुआत की थी. खास तौर पर, JavaScript और V8 में मेमोरी मैनेजमेंट की बुनियादी बातों को कवर किया गया है. आपने टूल इस्तेमाल करने का तरीका जाना. इनमें, Chrome के नए वर्शन में उपलब्ध ऑब्जेक्ट ट्रैकर की नई सुविधा भी शामिल है. इस जानकारी की मदद से, Gmail की टीम ने मेमोरी के इस्तेमाल से जुड़ी समस्या को हल कर लिया. साथ ही, Gmail की परफ़ॉर्मेंस भी बेहतर हुई. वेब ऐप्लिकेशन के लिए भी ऐसा किया जा सकता है!