2010-10-31 17 views
26

Arkaplan beklendiği gibi çöp toplama oluşmaz, hafızayı boşaltmak için başarısız: Şu anda (virtual desktop demo çalışan) MochaUI kitaplığı kullanan bir intranet sitesinde çalışıyorum. Mootools 1.2.4 ve MochaUI 0.9.7 kullanıyorum. "Sanal masaüstü" uygulamamda açılan pencereler, içeriklerini iframe'ler aracılığıyla yükler. Yüklenen sayfaların bazıları, css ve komut dosyası oluşturma açısından oldukça ağırdır, bu nedenle Window nesnelerinin, kullanıcı bir pencereyi kapattığında toplanması yeterlidir. Bu, görünüşte kütüphane tarafından halledilir (Firefox'u kullanırken adil bir iş yapar).Krom (Mootools/MochaUI kütüphane)

Güncelleştirme İlk olarak gönderilen soru sonraki düzenlemeler/güncelleştirmelerden çok daha uzun sürebilir hale gelmişti. Başlık artık doğru değildi, ben de bunu değiştirdim. Ayrıca kısmi bir çözüm için aşağıdaki cevabıma bakın. İşte

temel noktalar şunlardır:

  1. Krom şöyle yukarı Goofs:

    • Krom onlar kapalı yaparken MochaUI pencere nesneler için ayrılan belleği boşaltmak için başarısız olur. Bunun yerine, Chrome'un bellek kullanımı, pencerenin iframe içeriğini yüklemesini tamamladıktan sonra erişilen düzeye (tam anlamıyla) döner ve sayfa yenilenene kadar bellek kullanımına daha düşük bir sınır koyar.
    • İşlem tarafından kullanılan bellek, sonraki pencere açıklıkları/kapanmaları ile artmaya devam eder. Sonunda, bir tür kapağa ulaşıldı ve bellek kullanımı, hızlı bir şekilde yukarı sıçramak yerine hızla salınmaya/salınmaya başlıyor.
    • Bu sorun, söz konusu pencerelerin oldukça ağır (iframe) iframe içeriği yüklerken en belirgindir. Tüm test amaçları için kullanıyorum pencere, iframe bir 580 kb sayfası (önbelleğe alınmamış) yükler. Garip
  2. , gerçekleşecek yapar beklenen çöp toplama,

    • ardından tarayıcının başka sekme aynı tarayıcı penceresinde açılır
    • minimize edilir
    • bir Bellek Zaman Çizelgesi Geliştirici Araçları'nda kaydediliyor. (komedi seçeneği)
    • Bu davranış # 1'in çözümünde olası yaklaşımları önerir mi?
+5

Çok ilginç bir soru ve iyi bir açıklama. Ben suçlu ne olduğunu tam olarak emin değilim, sizi uyarmak rağmen bir çözüm olmayacak bir şans var. Ya da bir tane varsa, kolay değil. Google, programlamaya çok tembel bir yaklaşım benimsiyor. Chrome en hızlı yüklenen ve her büyük tarayıcıdan en az bellek kullansa da, Firefox veya Opera'da hayal edemediğim hatalarla dolu. Android ve iOS ile aynı. – stevendesu

+0

Bu sorunun çok ayrıntılı/uzun bir sürümünü Google'ın Chrome Web Yöneticisi yardım forumuna gönderdim ve bir yanıt almadım, bu yüzden bu noktaya daha fazla odaklanmaya karar verdim! Bunun bir hata gibi göründüğünü kabul ediyorum (veya Chrome'un hangi çöplerin toplanacağını nasıl belirlediğine dair bir tuhaflık). Chrome küçültüldüğünde ortaya çıkan daha yorucu bir çöp koleksiyonu varmış gibi, ve benim pencere objelerim Chrome'un standartlarına göre tamamen çöp değil. Yorum için teşekkürler! – freenatec

+4

@steven_desu: Google, programlamaya yönelik tembel bir yaklaşım benimsemekle kalmıyor, aynı zamanda kullanıcılarının ortaya çıkardığı herhangi bir şikayete veya soruna karşı da oldukça ilgisiz görünüyor. –

cevap

6

Bu Windows test edildi emin değilim, ama eğer öyleyse sen pencerelerde bir pencere minimize yazmasa bile belleği dosyası için tüm verileri taşır unutmayın. Pencereyi tekrar açtığınızda, program bunlara erişmeye çalışmadıkça bellek bloklarını geri hareket ettirmeyecek ve böylece herhangi bir çöplük sayfa dosyasında kalmayacak ancak aslında toplanmayacaktır.

Eğer otomatikleştirirseniz, yalnızca programı yavaşlatmaz, aynı zamanda herhangi bir bellek sorununa yardımcı olmaz.

https://micksmix.wordpress.com/2010/01/08/why-does-task-manager-show-an-applications-memory-usage-drop-after-minimizing-it-to-the-the-taskbar/

+0

Siteyi kullanan tüm intranet makinelerinde Windows XP çalıştıran, inanıyorum. Bu sorunu sayfa diskiyle değerlendirmemiştim, ancak Chrome'u Küçültülmüş durumuna (bir şekilde, herhangi bir etki için) otomatikleştiren/kandırmak uzun süren bir kavramdı ...İdeal olarak, javascript kodumu değiştirmenin bir yolunu bulabilirim. Böylece, Chrome, toplanan çöplerin olağan şekilde tanımlanmasını sağlar. – freenatec

+1

Onlarla bittiğinde değişkenleri/nesneleri null olarak ayarlamayı denediniz mi? – William

+0

Pencerenin kapanış davranışını işleyen kitaplık işlevlerini kavradığım kadarıyla, bir pencere kapandığında ilgili tüm nesneleri null olarak ayarlar. Pencerelerde yüklenen içerik (iframe'ler) daha fazla kendi kodumdur ve biraz dağınıktır ve muhtemelen sızıntılara katkıda bulunur. Ancak, Windows kapatıldığında Firefox'un belleği açtığını unutmamalıyım. MB yaklaşık 5 saniye boyunca). Diğer yandan, ilgili Chrome sürecinin bellek kullanımı, pencereler kapalıyken sabit kalır ve onu azaltan tek şey tarayıcıyı en aza indirmektir. – freenatec

3

Güncelleme
MochaUI closingJobs işlevi aşağıdaki değişiklikleri Ben daha önce burada yayınlanan içeriği üzerinde büyük gelişme vardır biraz daha fazla bilgi için aşağıdaki url bakın. Ana değişiklik şimdi, windowEl.destroy yöntemi DOM'dan iframe'i kaldırdığında ateş etmek yerine, src özelliğini değiştirerek iframe'in onunload olayı elle çağrılır. (fikri here'dan aldım).

Bu kodu kullanmak isterseniz, mevcut shutdownJobs işlevini silin ve bu kodu kopyaladığınız yere yapıştırın. Bu , 0.9.7 ve 0.9.8 MochaUI ve Mootools 1.2.4 veya 1.3 ile çalışmalıdır.


closingJobs: function(windowEl){   
    windowEl.setStyle('visibility', 'hidden'); 
    var instances = MUI.Windows.instances; 
    var instance_id = windowEl.id 
    var cleanup_delay = 50; 

    /* 
    Reset canvases with width/height = 0. 
    This pretty reliably frees a few hundred Kb of 
    memory in chrome. 
    */   
    instances[instance_id].canvasControlsEl.width = 0; 
    instances[instance_id].canvasControlsEl.height = 0; 
    instances[instance_id].canvasEl.width = 0; 
    instances[instance_id].canvasEl.height = 0;   

    if(instances[instance_id].options.loadMethod == 'iframe') 
    { 
/* 
The following line determines how long to delay the execution of 
the windowEl.destroy function. The line below gives 10 milliseconds 
per DOM element in the iframe's document. 
You could probably do just as well with a hard-coded value. 
*/   
     cleanup_delay = instances[instance_id].iframeEl.contentDocument.getElementsByTagName("*").length * 10;    

/* 
Set the Browser property in the iframe's window to Internet Explorer. 
This causes Mootools to run its purge function, which iterates over 
all the iframe document's DOM elements, removing events/attributes etc. 
Assuming you have mootools included in the iframe content.  
*/ 
     if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools) 
     {   
      if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools.version.contains("1.3"))     
       instances[instance_id].iframeEl.contentDocument.defaultView.Browser.ie = true; 
      else   
       instances[instance_id].iframeEl.contentDocument.defaultView.Browser.Engine.trident = true; 
     }     

     instances[instance_id].iframeEl.src = "javascript:false"; 
    }  

    MUI.cleanWindow.delay(cleanup_delay, null, windowEl);  
}, 

cleanWindow: function(windowEl) 
{        
    var instances = MUI.Windows.instances; 
    var instance_id = windowEl.id 
    if (Browser.ie){ 
     windowEl.dispose(); 
    } 
    else { 
     windowEl.destroy(); 
    }  
    instances[instance_id].fireEvent('onCloseComplete'); 

/* 
Changed - Only execute getWindowWithHighestZindex() and focusWindow() 
functions if there will actually be open windows after the 
current one closes. 
*/ 
    if (instances[instance_id].options.type != 'notification' && instances.__count__ > 1){ 
     var newFocus = MUI.getWindowWithHighestZindex(); 
     MUI.focusWindow(newFocus); 
    }  
    if (this.loadingWorkspace) this.windowUnload(); 
    if (MUI.Dock && $(MUI.options.dock) && instances[instance_id].options.type == 'window'){ 
     var currentButton = $(instances[instance_id].options.id + '_dockTab'); 
     if (currentButton != null){ 
      MUI.Dock.dockSortables.removeItems(currentButton).destroy(); 
      currentButton = null; //Is this necessary? 
     }   
     MUI.Desktop.setDesktopSize(); 
    } 

    //Changed - moved this to the end of the function. 
    delete instances[instance_id]; 
} 
+1

, hangi mootools sürümü kullanılıyor. mootools 1.3 biraz basitleştirilmiş element.prototype.destroy bu yüzden şöyle görünüyor: http://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L677 vs eski bir http:/Yukarıdaki garip 'clean() işlevine giden /github.com/mootools/mootools-core/blob/1.2x/Source/Element/Element.js#L579. –

+0

1.2.4. Aynı şeylerin 1.3 ile gerçekleştiğini görüyorum (0.9.7 MochaUI yapısıyla). Benim testimde uyum katmanını kullandım, bunun bir faktör olup olmadığından emin değilim. Yukarıda önerdiğim düzeltme, Chrome'un 1.2.4'teki gibi 1.3'teki bellek davranışında aynı etkiye sahip. Yine de tüm bunlar değişebilir: ilk yorumunuza dayanarak mochai'nin github'unda biraz daha fazla eğlendim - 0.9.8 şubesinin son zamanlarda bu kadar çok aktiviteye sahip olduğunun farkında değildim! Onu dikkatime sunduğun için teşekkür ederim. – freenatec

+0

Merak etme! Eski mochaui ile çalışmak zordu. Uygulamak zorunda olduğum çok sayıda düzeltmeden dolayı hala kendi şubemi destekliyorum ve şimdi 0.9.8 veya 1.0'ı kullanmak imkansız olacak! Oh iyi! –