[bug/fp] De frontpage lekt geheugen in Chrome

[NetForce1]

De frontpage lekt geheugen in Chrome, ik heb hem nu zo'n twee weken open staan en volgens about:memory heeft de tab 878508k aan private memory in gebruik. De gerapporteerde waarden zijn als volgt:
Private Memory: 878508k
Shared Memory: 7968k
Total Memory: 886476k
Virtual Private memory: 1403484k
Virtual Mapped memory: 2936k

Ik gebruik de dev-versie van Chrome 5, maar heb het in eerdere versies ook al gezien (ook non-dev versies).

[ACM]

Websites zijn doorgaans niet echt bedoeld om weken lang open te laten staan. Doordat er allerlei Ajax-requests worden gedaan voor bijvoorbeeld het verversen van de tracker links zal er inderdaad wel langzaamaan wat meer geheugen gebruikt worden.
Vziw laat die ververs-implementatie echter geen oude objecten gerefereerd staan, dus zou er in principe op een gegeven moment een status-quo in het geheugengebruik moeten ontstaan. Vooropgesteld natuurlijk dat de Javascript-VM een goed geheugenbeheer heeft dat past bij het open laten staan van de pagina.

Heb je ook andere pagina's met ajax-verkeer e.d. langere tijd open laten staan?

[moto-moi]

ACM schreef op donderdag 24 juni 2010 @ 19:09:
Websites zijn doorgaans niet echt bedoeld om weken lang open te laten staan. Doordat er allerlei Ajax-requests worden gedaan voor bijvoorbeeld het verversen van de tracker links zal er inderdaad wel langzaamaan wat meer geheugen gebruikt worden.

Ik vind eigenlijk dat zoiets nooit een probleem kan zijn van een website, bij elke refresh kijk je tenslotte naar eenzelfde pagina, als je browser dan allerlei geheugen lekt, is dat een browserprobleem.

[ACM]

moto-moi schreef op donderdag 24 juni 2010 @ 19:43:
Ik vind eigenlijk dat zoiets nooit een probleem kan zijn van een website, bij elke refresh kijk je tenslotte naar eenzelfde pagina, als je browser dan allerlei geheugen lekt, is dat een browserprobleem.

Wel als wij (dus buiten een browser-refresh om) steeds elementen zouden toevoegen aan bijv de document-node in de DOM. Maar vziw gebeurt dat daar niet.

[crisp]

Mja, dit is voor ons dus puur gissen en kan dus ook gewoon aan de browser liggen. Fijn dat je het meldt, maar zonder concrete pointers kunnen wij hier heel weinig mee. Verder is dit natuurlijk ook geen normale gebruikerssituatie (een tab twee weken open laten staan).

Overigens is het ook zo dat de ajax-verwerking gepauseert wordt op het moment dat er een tijdje geen fysieke activiteit is op de pagina, en zijn er ook nog zaken waar wij verder weinig invloed op hebben (banners bijvoorbeeld).

[moto-moi]

ACM schreef op donderdag 24 juni 2010 @ 19:54:
Wel als wij (dus buiten een browser-refresh om) steeds elementen zouden toevoegen aan bijv de document-node in de DOM. Maar vziw gebeurt dat daar niet.

Dan is het nog aan de browser om een goede garbage collector daarvoor te hebben, zeker nu ajax al enige tijd veelgebruikt wordt, ook op de sites van de makers van dat chrome ding

[Soultaker]

Nee, want objecten die gewoon nog via-via te bereiken zijn (omdat ze in de DOM tree zitten bijvoorbeeld, of omdat er ergens via JavaScript datastructuren aan gerefereerd wordt) kun je niet garbage collecten.

Een beetje Googlen leert dat als je Chrome start met --js-flags="--expose_gc" je door javascript:window.gc() aan te roepen via de location bar de GC kunt draaien. Als er dan nog steeds onnodig veel geheugen in gebruik is, dan zit het probleem (voor zover het een probleem te noemen is) 'm in de website (of de GC werkt niet goed).

[NetForce1]

Meteen nadat ik dit gepost had heb ik mijn browser opnieuw gestart, en tweakers.net geopend en nu.nl. Tweakers.net stond zojuist op ong. 121000k terwijl nu.nl het bij ong. 16000k hield. Toch wel een significant verschil lijkt me.
Natuurlijk snap ik ook wel dat half-brakke gc-implentaties hier de oorzaak van kunnen zijn. Maar melden kan ook geen kwaad dacht ik, wellicht gaat er nog bij iemand een lampje branden.

Overigens wilde ik bij het maken van deze post even kijken of ik een heap snapshot kon maken met de Developer Tools van Chrome en toen crashte de hele boel...