कचरा बाहर निकालो!

यह विभिन्न ब्राउज़रों में कचरा संग्रहण और मेमोरी लीक के बारे में है।



सामान्य तौर पर, इस विषय पर पहले ही बहुत चर्चा हो चुकी है, मैं एक दिलचस्प मामले को बंद करने पर विचार करना चाहता हूं।





सी # में बंद होने के कार्यान्वयन के साथ शुरू करने के लिए, केवल उन वस्तुओं को जो वास्तव में आंतरिक फ़ंक्शन में उपयोग किया जाता है, और सभी दृश्यमान चर नहीं हैं, संदर्भित किया जाएगा। मुझे C # और जावास्क्रिप्ट के व्यवहार की तुलना करने में दिलचस्पी थी। चूंकि कई जेएस कार्यान्वयन हैं, और वे सभी अलग हैं, मैंने यह परीक्षण करने का निर्णय लिया कि यह लोकप्रिय ब्राउज़रों में कैसे लागू किया जाता है।



टेस्ट होंगे: IE, क्रोम, FF और ओपेरा। ओएस: win7 32 बिट।



तो, चलो बस स्मृति का एक बड़ा हिस्सा आवंटित करके शुरू करें:

टेस्ट 1 (मेमोरी आवंटन):

function test1() { var buff = []; for (var i = 0; i < sz; i++) buff.push(i); alert(1); var buff2 = []; for (var i = 0; i < sz; i++) buff2.push(sz - i); alert(2); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मैं कार्य प्रबंधक (निजी कामकाजी सेट) द्वारा मेमोरी को मापता हूं, यह, ज़ाहिर है, पूरी तरह से सही नहीं है, लेकिन यह ट्रैकिंग परिवर्तनों के लिए उपयुक्त है।

स्मृति खपत में परिवर्तन (केबी में) क्रम में जाना:

→ → पहला अलर्ट → दूसरा अलर्ट (कोष्ठक में - परिवर्तन)

यदि परिवर्तन मामूली हैं, तो मैं इसे निरूपित करूंगा (~ 0)



IE8: sz = 2e6;

आइए IE8 से शुरू करते हैं, यह एक बहुत ही धीमा ब्राउज़र है, इसलिए इसके लिए हम सरणी का आकार लेते हैं (sz) - 2 मिलियन

मेमोरी: 9036 → 87476 → 167880 (+78440, +80404)

चलो थोड़ा इंतजार करें (कचरा कलेक्टर अचानक काम करेगा), लेकिन मेमोरी कम नहीं होती है।

पुन: प्रयास करें: 167868 → 248260 → 328640 (+80392, +80380)

फिर से एक ऐसी ही तस्वीर। मैं इस प्रक्रिया को दोहराया जब तक IE 1GB स्मृति खा लिया। मैंने उसे आधे घंटे के लिए अकेला छोड़ दिया (और अचानक वह अभी भी कचरा हटा देगा), लेकिन कुछ भी नहीं बदला है।

निष्कर्ष : जब तक आप टैब को बंद नहीं करेंगे, तब तक IE8 स्वयं कचरा नहीं निकालेगा / F5 दबाएगा।



क्रोम 8.0.552.237): sz = 10e6;

अगला क्रोम आता है (शायद नवीनतम संस्करण नहीं है, लेकिन मुझे लगता है कि आपको मजबूत बदलाव की उम्मीद नहीं करनी चाहिए)

मेमोरी: 5072 → 78480 → 143624 (+73408, +78480)

प्रतीक्षा: 143676 (~ 0)

परीक्षण फिर से चलाएं: 143676 → 72636 → 112604 (-71040, +39968)

फिर से इंतजार: 112608 (~ 0)

तीसरा लॉन्च: 112608 → 96092 → 148704 (-16516, +52612)

प्रतीक्षा: 148700 (~ 0)

लंबे समय तक प्रतीक्षा करें (मिनट 5): 5356 (-143344)

निष्कर्ष : क्रोम या तो कचरा तब निकालता है जब आवंटित मेमोरी एक निश्चित सीमा तक पहुंच जाती है, या खुद, बल्कि लंबे समय के अंतराल के बाद।



फ़ायरफ़ॉक्स 3.6.13: sz = 20e6;

ओगेलिस ने बहुत अधिक मेमोरी का उपभोग नहीं किया, इसलिए इसके लिए एक बड़े सरणी आकार का उपयोग किया जाता है:

मेमोरी: 39064 → 124968 → 211180 (+85904, +86212)

प्रतीक्षा करें: 211164 (~ 0)

कोशिश 2: 211164 → 297480 → 383592 (+86316, +86112)

प्रतीक्षा करें: 211280 (-172312)

प्रतीक्षा: 38908 (-172372)

निष्कर्ष : फ़ायरफ़ॉक्स क्रोम की तुलना में तेज़ी से कचरा इकट्ठा करता है, लेकिन ऐसा करने में कुछ समय लगता है (~ 1min)।



ओपेरा 11.00 (बिल्ड 1156): sz = 10e6;

मेमोरी: 20६४३६ → ३४ ९ २४४ → ६१२० ९ ६ (५:२ ,० +26, ५:२64५२)

प्रतीक्षा करें: 87736 (-524360)

कोशिश २: 100100३६ → ३४ ९९ २ → → ६१२१०० (५:२१ ९ २, ५:२१ 8२)

प्रतीक्षा करें: 87748 (-524352)

ओपेरा ने अन्य पर्याप्त ब्राउज़रों की तुलना में बहुत अधिक मेमोरी का उपभोग किया (अधिक सिर्फ IE है), लेकिन इसने लगभग तुरंत ऐसा किया। स्मृति को भी लगभग तुरंत जारी किया गया था।



सभी ब्राउज़रों के लिए अंतिम परिणाम:

IE8 - धीमा, प्रत्येक संख्या के लिए ~ 40 बाइट्स आवंटित करता है

Chrome8 - औसत गति, प्रति नंबर ~ 8 बाइट्स आवंटित करता है

FF3.6 - औसत गति, प्रति नंबर ~ 4.4 बाइट्स आवंटित करता है

ओपेरा 11 - उच्च गति, प्रत्येक संख्या के लिए ~ 27 बाइट्स आवंटित करता है (sz = 10e6 के साथ)

और ~ 16 बाइट sz = 1e6 के साथ

Test2 (स्पष्ट मुक्त मेमोरी):

IE को यह कहने के लिए मजबूर करने की कोशिश करें कि हमें अब इस मेमोरी की आवश्यकता नहीं है

IE8: sz = 2e6;

लंबाई की कोशिश करें = 0:

मेमोरी: 10912 → 89352 → 169760 → 169760 → 169760

बफ़ को हटाने का प्रयास करें:

मेमोरी: 12848 → 89356 → 169752 → 169740 → 169740

विभाजन का प्रयास करें:

मेमोरी: 12972 → 89464 → 169852 → 250368 → 330760,

यहां, ऐसा लगता है, एक प्रतिलिपि बनाई गई है, लेकिन सरणी का पुराना संस्करण साफ़ नहीं किया गया है

पॉप प्रयास करें:

मेमोरी: 6776 → 85192 → 165508 → 165508 → 165508

परिणाम : पूर्ण विफलता। IE8 का कचरा संग्रहक एक मिथक है।



जाहिर है, हम केवल तीन शेष ब्राउज़रों पर क्लोजर का उपयोग करके कचरा संग्रह का परीक्षण करेंगे।

टेस्ट 3 (जो वस्तुएं बंद हो जाती हैं):

 function test3() { var buff = []; for (var i = 0; i < sz; i++) buff.push(i); alert(1); var buff2 = []; for (var i = 0; i < sz; i++) buff2.push(sz - i); alert(2); return function(x) { alert(buff.length); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Chrome 8: sz = 10e6;

मेमोरी: 4796 → 72720 → 139956 → -05 45232

→ → इसके बाद के प्रतीक का अर्थ होगा कचरा संग्रहण की प्रतीक्षा करना

दूसरा प्रयास: 8924 → 88000 → 135100 → -05 135092

तीसरा प्रयास: 135092 → 151036 → 174128 → -05 46092

परिणाम : केवल संदर्भित बंद में लिया जाता है, जीसी अपेक्षित रूप से काम करता है, लेकिन बहुत लंबे समय के लिए।



फ़ायरफ़ॉक्स 3.6: sz = 20e6;

मेमोरी: 39864 → 124812 → 210752 → -05 124560

दूसरा प्रयास: 124560 → 210772 → 296928 → -05 124544

परिणाम : केवल संदर्भित क्लोजर में मिलता है, जीसी अपेक्षित रूप से काम करता है।



ओपेरा 11: sz = 10e6;

मेमोरी: 102072 → 364268 → 626448 → -05 364760

दूसरा प्रयास: 364760 → 626940 → 889108 → -05 364752

परिणाम : खपत की गई स्मृति को देखते हुए, केवल संदर्भित बंद में मिलता है, जीसी अपेक्षित रूप से काम करता है; हालाँकि, ऐसा बिलकुल भी नहीं है ...



अब js इंजन के साथ कार्य को थोड़ा जटिल करते हैं: क्लोजर के अंदर eval () डालें

Test4 (अंदर eval के साथ बंद):

 function test4() { var buff = []; for (var i = 0; i < sz; i++) buff.push(i); alert(1); var buff2 = []; for (var i = 0; i < sz; i++) buff2.push(sz - i); alert(2); return function(x) { alert(buff[0]); eval(x); } } function z() { document.getElementById("div1").x("alert(buff2[0])"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 <div onclick="this.x = test4()" id="div1">test4()</div> <div onclick="z()">z()</div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जाहिर है, अब सभी चर को बंद होने से बचाया जाना चाहिए: क्या यह हमारे लिए नहीं है?



क्रोम:

क्रोमियम के लिए एक विश्वसनीय परिणाम प्राप्त करना मुश्किल है, क्योंकि कचरा संग्रहण के लिए लंबे समय तक प्रतीक्षा करें।

लेकिन आवंटित मेमोरी और इस तथ्य को देखते हुए कि z () परीक्षण कार्य करता है, हम यह निष्कर्ष निकाल सकते हैं कि सब कुछ उम्मीद के मुताबिक काम करता है।



फ़ायरफ़ॉक्स 3.6: sz = 20e6;

मेमोरी: 39300 → 125696 → 210732 → -05 210256

दूसरा प्रयास: 210256 → 298340 → 383496 → -05 211112

परिणाम : eval के साथ एक क्लोजर सभी घोषित चर को संदर्भित करेगा। जैसी की उम्मीद थी।



ओपेरा 11: sz = 10e6;

मेमोरी: 102076 → 364272 → 626456 → -05 364764

मेमोरी को देखते हुए, क्लोजर में eval को नजरअंदाज कर दिया जाता है, हालांकि, eval के साथ z () टेस्ट सही तरीके से होता है।



बहुत अप्रत्याशित व्यवहार। यदि स्मृति पहले ही इससे मुक्त हो गई है तो बफ़ 2 सरणी कहाँ से आती है? क्या ओपेरा किसी तरह बड़े सरणियों के भंडारण का अनुकूलन कर सकता है?



आइए देखें कि क्या होता है यदि आप सिर्फ सरणी लौटाते हैं:

test5:

 function test5() { var buff = []; for (var i = 0; i < sz; i++) buff.push(i); alert(1); var buff2 = []; for (var i = 0; i < sz; i++) buff2.push(sz - i); alert(2); return { a: buff, b: buff2 }; //return { a: buff }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ओपेरा:

2 ऑब्जेक्ट: 41764 → 304324 → 567088 → -05 304556

1 वस्तु: 41896 → 304348 → 567108 → -05 173240



ऐसा लगता है कि ओपेरा वास्तव में किसी भी पूर्ण होने के बाद विशाल सरणियों को पैक करता है।

लेकिन इसका मतलब यह है कि 4 और 3 परीक्षणों में, वह दायरे से सभी चर का संदर्भ देती है।



तो, InternetExplorer भी संस्करण 8 स्मृति के साथ बहुत काम करता है।

फ़ायरफ़ॉक्स और क्रोम बड़े ऐरे को बहुत संयम से संभालते हैं (जो आप उन्हें बधाई दे सकते हैं) और तार्किक रूप से क्लोज़र को ऑप्टिमाइज़ करें।

दूसरी ओर, ओपेरा सभी दृश्यमान चर को बंद कर देता है, जो सिद्धांत रूप में बुरा नहीं है, लेकिन आपको हमेशा ध्यान रखना चाहिए और साइट पृष्ठों पर स्क्रिप्ट नहीं बनाना चाहिए जो 10 मिलियन संख्याओं के सरणियों को निकालते हैं।



PS:

chepetsk.ru

:

ibm.com/developerworks/web/library/wa-memleak/

blogs.msdn.com/b/oldnewthing/archive/2006/08/02/686456.aspx