Kolko memory browser dlhodobo zozere nezalezi celkom od toho ako je aplikacia napisana a optimalizovana, ale od styroch veci:
1. Ako browser alokuje pamat a potlacuje fragmentaciu
2. Ako browser naraba s objektami na stranke
3. Ako browser naraba s cache
4. Memory leaks v aplikacii a pluginoch
Pomerne zasadny vplyv ma pouzitie alokatoru pamate. V Mozille bola dlha diskusia aky alokator pouzit pre Firefox 3 a nove Gecko. Nakoniec volba padla na jemalloc, ktory sa pomerne pracne prepisal z FreeBSD na podporovane platformy. Iba jednoducha vymena alokatoru znizila pamatove naroky Firefoxu o 20%.
Dnes je sice trend davat mnoho veci do RAM, ale zaroven je aj trend to uvolnit tak rychlo, ako je to len mozne. Preto dost zalezi ako browser naraba s objektami (obrazky, animovane GIFy, video), U IE7, Safari, ciastocne u Opery napriklad zostavaju rozbalene images stale v RAM, aj ked tab je neaktivny. U Firefox 3 idu rozbalene data obrazku okamzite prec, dokonca aj z image cache a tato pamat sa uvolni. Animovane GIFy su ukladane ako 8 bitove data plus paleta na rozdiel od inych browserov, ktore ich ponechavaju ako 32-bitove.
Dalsie vec je ako ma browser nastavene casovace na uvolnovanie cache. Toto je vzdy vecou vyvojoveho timu, aby nasiel rovnovahu medzi vykonom a spotrebou RAM. Opera ma napriklad velmi dlhy casovac back/forward cache a font cache na rendering pisma, Firefox 3 zmenil casovac pri back/forward cache na 30 minut, font cache je este kratsia.
No a memory leaks. Mnohi sa stazuju, ze pluginy k Firefox maju strasne vela bugov a sposobuju rozsiahle uniky pamate. Netvrdim, ze dnes je vsetko OK, ale casy, ked boli situacia kriticka, su uz davno prec. Firefox 3 ma novy XPCOM cycle collector, ktory dokaze detekovat zacyklene objekty a uvolnit ich z memory, takze ak plugin napisal clovek, ktory tomu nevenoval pozornost, da sa to pomerne uspesne redukovat.