Jeden z paměťových problémů Firefoxu: fragmentace

Christopher Blizzard, jeden z přispěvatelů do kódu Mozilly a člen rady Mozilla Corp., přiznal, že paměťová náročnost Firefoxu představuje důležitý problém, a to obzvláště nyní, když se chce Firefox protlačit na mobilní zařízení. Jiný vývojář Mozilly Stuart Parmenter nyní také zjistil, že závažným důvodem pro spotřebu může být fragmentace paměťového prostoru.

12.11.2007 21:01 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Kyosuke]

Ha! To jen jasně ukazuje výhody compacting garbage collectorů...

[deda.jabko]

to by mozna chtelo vyzkouset vyhodit z mozilly vsechny ty hnusne smart pointers... a nahradit je nejakym ,,general purpose'' collectorem... zajimalo by me, o kolik by se zlepsila/zhorsila rychlost a spotreba... osobne tipuju, ze by oboji slo k lepsimu...

[2007]

Ak by mal taku spravu pamati ako Java, tak by zaberal nie 40 MB ale 140 MB.

[cronin]

FUD

[Bob Bobovich]

Ta čísla berete kde? Mně momentálně firefox zabírá 382 MB RAM :-/

[2007]

Pomocou programu top stlpec RES.
Firefox mi po starte zabera 31 MB (jeden tab about:blank).
Eclipse bez otvoreneho projeku 171 MB
KDevelop bez otvoreneho projeku 27 MB
Vsetky programy su 64-bitove.

[ivan]

No oni ty jejich smart pointery patri k tomu lepsimu co se ve zdrojacich mozilly nachazi. Treba pro stringy ma mozilla dokonce 6 ruznych trid, ktere se lisi implementaci a ucelem k cemu je chcete pouzit. Bohuzel se mezi tema stringama neda castovat. Tzn. nemuzete napsat a=b, pokud jsou a b instance ruznych trid implemetujici string. Takze to nakonec skoncilo tim ze se na vetsine mist pouziva char *, nebo jeste lepe void**. To je datovy typ do ktereho ulozite prakticky cokoliv. S dealokaci uz je to horsi, dokumentace k XPCOMU se vubec nevenuje tomu, kdo ma vlastne dealokovat predavany objekt. Dulezite je ale doporuceni, neprovadejte new/delete pokud vase metoda bezi mimo kontext hlavniho vlakna.

[xkucf03]

Zrovna jsem chtěl vyhlásit flame: "Jaké myslíte, že by to bylo, kdyby FF psali v Javě?" Ale předběhl jsi mě

Jazyky, kde má programátor více volnosti mu sice dávají v některých případech možnost napsat kód teoreticky lepší, jenže v praxi toho málokterý programátor využije a většinou to IMHO dopadne hůř, než kdyby to nechal na GC a podobných vymoženostech vyšších jazyků.

[Miloslav Ponkrác]

Velmi pochybuji o tomto závěru - velmi pochybuji, že hlavní paměťový problém Firefoxu je fragmentace.

Mimochodem, kdysi jsem chtěl něco pro Mozillu naprogramovat, tak jsem začal číst jejich manuály a popis stylu a dnes se vůbec divím, že jejich programy nějak chodí - to je zázrak, ke kterému museli dopomoct ufouni. Něco tak blbého, jako je jejich styl programování jsem už dlouho neviděl a to už jsem měl v rukách leccos. Vyhodili z C++ asi tak 98% užitečných věcí a udělali z toho vzdálenou imitaci COM modelu z Windows. A když jsem viděl některé zdrojové kódy, musel jsem si cvaknout, střízlivý jsen to nesnesl.

[Kyosuke]

To jste z toho ještě vyvázl docela dobře. Považte, že byste z toho mohl chytnout třeba ropuchu osobnosti.

[Miloslav Ponkrác]

Když tak mluvíte o těch nebezpečích co se může stát při studiu zdrojových kódů Mozilly - existuje nějaká cesta jak vyúčtovat týmu Mozilly náklady na nezbytný alkohol, který jsem musel požít při pokusu studovat jejich zdrojové kódy?

[kavol]

Velmi pochybuji o tomto závěru - velmi pochybuji, že hlavní paměťový problém Firefoxu je fragmentace.

ale chlapče, to jsi zaspal dobu, neovládáš newspeak ... tak jako challenge = problém, tak fragmentace paměti = totálně zprasený kód alokující nesmysly, sem tam nějaký leak

[Miloslav Ponkrác]

A sakra, tak to mám zase co dohánět.

[R]

To teda fakt skoro zistili... O dva roky mozno este zistia, ake nechutne naroky na CPU to ma.

[Drom]

+1

[Deleted [8409]]

Mi zabírá firefox po asi 2 dnech používání okolo 200MB, je to víc, než třeba Visual Studio, které je napsané v .NET.

Jestli s tím něco neudělají, tak nemají na mobilní sféru šanci. Tam vládne Opera a WebKit na tom bude určitě taky mnohem líp :)

[Kyosuke]

Visual Studio AFAIK není napsané v .NETu, většina z toho jsou poslepované COM komponenty.

[Deleted [8409]]

Tak zkuste odinstalovat .NET a uvidí se, jestli se to rozjede. Neříkám, že je celé napsané v .NET, ale určitě na tom svůj podíl má.

[Kyosuke]

"Tak zkuste odinstalovat .NET a uvidí se, jestli se to rozjede."

A to s tím jako souvisí jak přesně? Tím nedokážu vůbec nic.

[Deleted [8409]]

Tím dokážu, že je .NET potřeba pro to, aby to fungovalo.

[Kyosuke]

Jak naivní. Když vytáhnu z počítače napájecí šňůru a ten přestane fungovat, znamená to, že když vytáhnu procesor a zase zapojím šňůru, bude fungovat i bez procesoru? Hint: Tohle tvrzení (o Visual Studiu) jsem onehdá našel na blogu zaměstnance Microsoftu. Nemám to z vlastní hlavy. Ale budu to muset zpětně dohledat.

[Deleted [8409]]

Klidně hledejte

Ale ne že mi zachvilku řeknete, že pro Eclipse není potřeba Java:)

[Kyosuke]

Nevím, co znamená "není potřeba Java", když je to v Javě (programovacím jazyku) napsané, ale přinejmenším JRE zapotřebí opravdu není, existují i nativní buildy.

[Deleted [8409]]

Já ale opravdu nemám náladu se tady handrkovat o slovíčka. Ať napíše čárku ten, kdo to nepochopil...

[Kyosuke]

Mno, slovo "Java" má spoustu významů, třeba "v telefonu mám Javu" určitě neznamená, že tam má uloženou Steelovu referenci. A handrkovat se o slovíčka opravdu není třeba, ale přinejmenším bys nemusel vypouštět taková poloinformovaná prohlášení, jako že "Visual Studio je napsané v .NET", když v managed kódu jsou psané maximálně jeho novější části, obzvlášť ve VS 2005. To je jako říct, že "lokomotiva je vyrobená ze šroubků". Kdepak, ty jen drží pohromadě větší části skládačky. Viz třeba tohle. Pokud 7,5 milionu řádků managed kódu ve VS2005 je jen zlomkem celkového objemu, pak paměťový footprint VS ještě nebude tak hrozný, když vezmeš v úvahu, že celé NetBeans nebo Eclipse mají podle Ohlohu právě asi těch ~7000000 řádků, a přitom mi tahle prostředí přišla náročnější nebo přinejmenším srovnatelně náročná.

[Deleted [8409]]

Ale to naměl být smysl toho všeho. Když napíšu jeden řádek v pythonu a propojím to celé s mojí aplikací, tak se tato aplikace stává na pythonu závislá (ať chci, nebo nechci) a natáhne si runtime.

Věřím, že asi o Visual Studiu něco víte, ale stejně musíte uznat, že ten runtime prostě běží, taky spotřebovává nějakou paměť a o to všechno tady celé šlo.

Prostě jak je možné, že firefox po 2 dnech práce zabírá 4x víc paměti, než Visual Studio po 2 dnech práce (bereme v úvahu, že zavřeme všechny otevřené soubory)?

[Miloslav Ponkrác]

Nějak mám pocit, že to srovnávání jablek s hruškama není ono. Ale jinak, když chcete srovnání, editor vim mi teď zabíral 550 MB RAM při editaci 300 MB souboru. A pokud by někdo věděl, jak donutit vim zobrazovat korektně celou unicode sadu znaků, pak budu šťastný člověk.

[Deleted [8409]]

To je úplně jedno. Prostě po 2 dnech zabírá firefox přes 200 MB i když zavřu všechno, Visual Studio zabírá třeba 40MB a je to program daleko větší a určitě komplexnější.

Porovnávám prostě paměťovou náročnost 2 programů po 2 dnech, to je všechno.

[Milan Jurik]

Jsem asi fakt slepy, ale jaky memory allocator uzil pro svuj experiment (hodil by se i pouzity OS)?

[Roger]

System jsou, pokud se nemylim, Windows. Alokator asi nejaky normalni :) Ten blogpost ma pokracovani s testem s Low Fragmentation Heap z XP+.

[JoHnY]

Pred par rokama, este za dob Mozilly 1.x.x (FF este nebyl) jeden muj kamarad objevil vcelku blbej bug a rozhod se, ze ho opravi a pomuze OS. Roky uz dela v C++, rek bych, ze je osoba povolana. Inu stahnul zdrojaky, dokumentaci a dal se do lusteni. Na ty jeho hlasky v ICQcku se jen tezko zapomina. Rozhodne jim ty zdrojaky nechvalil

Nedokazu posoudit jak moc prehanel (nejsem C++ pozitivni - bez sberace smeti ani ranu a s nejakou tou VM/Runtimem na vecne casy :)), ale uz dlouho mam pocit, ze Mozilla foundation ma super marketing a "prodava" pekene potluceny ovoce.

[Miloslav Ponkrác]

Ano ano, potvrzuji - můj pokus brodit se zdrojákama Mozilly skončil tím, že jsou to druhé nejhorší zdrojáky C/C++ co jsem měl kdy v ruce - a můj slovník a výrazy při tom se nedají publikovat ani v pokleslém bulvárním médiu.

Mozilla je prostě hnůj a shnilotina uvnitř, který je přelakován na růžovo a moderním marketinkem prodávaný jako to nejlepší ovoce. Vždycky se směju, když někdo kritizuje Windowsy, jak jsou příšerně naprogramovaný a do toho chválí Firefox.

[Michal Vyskočil]

že jsou to druhé nejhorší zdrojáky C/C++ co jsem měl kdy v ruce

A kdo nakonec vyhrál?

[Miloslav Ponkrác]

Jeden český programátor, jehož 20 KB velké zdrojové kódy v jazyce C jsem luštil 14 dní, než jsem rámcově pochopil, co dělá. Neprasil, je to jeho normální styl, a je to o něm veřejně známé, že jeho zdrojové kódy nejdou číst. Nicméně je perfektní systémový programátor a obrovský znalec vnitřností systému (mluvím o Windows), nicméně z pochopitelných důvodů nemůže pracovat v týmu.

Ale na rozdíl od Mozilly co napíše, je perfektně ošetřené a skvěle to chodí, naprosto bez chyby a dá se na to spolehnout, jen se to nedá po něm číst.

Schválně, jestli uhádnete o koho jde...

[Trained.Monkey]

neologism?

[Miloslav Ponkrác]

vedle

[zoul]

Mozilla je prostě hnůj a shnilotina uvnitř, který je přelakován na růžovo a moderním marketinkem prodávaný jako to nejlepší ovoce.

Mozilla je organizace. Myslíte Firefox? Nebo Gecko? Firefox je výborný prohlížeč. Jestli má blbě napsané zdrojáky (jako že asi ano, stěžuje si na ně hodně lidí), tak je to škoda, ale drtivá většina uživatelů to nikdy nezaznamená.

[miso]

drtivá většina uživatelů to nikdy nezaznamená.

Priamo nie, ale nepriamo urcite ano (pomaly vyvoj, neopravene chyby, ...)

[frEon]

nevsiml jsem si ze by byl firefox vyborny prohlizec... jediny co je na nem dobry je ze podporuje addons, ze kterych je par k necemu dobrejch.

[Petr Tomeš]

Já jsem si všiml a nejsem sám.

[Miloslav Ponkrác]

Blbě napsané zdrojáky jsou věc, která je snadno zaznamenatelná. Mnoho lidí je komerčně nuceno pro obživu se v takovém zdrojáku hrabat. Určitě i tým Mozilly placený AOL, nebo tým OpenOffice placený Sunem. Ale dobrovolně od toho většina nadšenců dá ruce pryč - koneckonců proč se hrabat v hnoji, když chci zažít radostné programování? V takových zdrojácích se čím dál hůře dělají úpravy, čím dál častěji zanášejí chyby, čím dál snadněji zůstávají memory leaky, atd.. Pak je potřeba veřejnosti lhát, jako že příčina není v prasáckosti programování Mozilly, ale ve fragmentaci paměti a jiné milosrdné lži.

[Michal Kubeček]

Po zjištění, jaké kuriozity zůstaly ve Firebirdu po programátorech od Borlandu, si to dokážu živě představit. Dospěl jsem k názoru, že důvodem, proč se firmám nechce do otevírání zdrojáků větších projektů, není strach o vykrádání drahocenného know-how, ale spíš obava, že by po zveřejnění svých zdrojáků ztratili i poslední zbytky dobré pověsti… :-)

[Miloslav Ponkrác]

Vážený pane, příprava zdrojáků na otevření chce dost práce - protože málokdo a málokterá firma, pokud píše program pro sebe ho má ve tvaru, kdy ho může přeložit každý. Je potřeba vyhodil lokální závislosti, upravit to tak, aby to přeložil každý, aby to nepoužívalo interní firemní věci, připravit skripty na překlady pro různé platformy a kompilátory, napsat dokumentaci, vyzoušet. I kdyby to bylo čistě napsané (jakože to dost často není), pořád to není jednoduchá akce.

A pak něco vydáte ven jako open source a lidi Vás začnou otravovat opravdu přínosnými debatami na téma "proč odsazujete bloky ve zdrojáku mezerami a ne tabelátory", "proč používáte pro názvy objektů první velké písmeno a ne malé", pár lidí Vám vysvětlí, že jste debil, a oni jsou mistři světa, ačkoli nic nedokázali, do toho pár nadšenců začne s tím, "proč to není pod GPL", a ono to profíky dost rychle přestane bavit.

Jinak dobře napsaných programů (i open source) je zoufale málo, naprostá většina z nich by šla napsat rozhodně méně prasečtěji.

[Kyosuke]

Pan Kubeček možná mluví mj. o tom hardcoded backdooru v Interbase (user: 'politically', password: 'correct'...a to se, prosím pěkně, sedm let v tomhle stavu prodávalo jako celkem bezpečný produkt. )

[Miloslav Ponkrác]

Aha, tak to se omlouvám, špatně jsem to pochopil. Ale je nutné říct, že v té době se backdoory vyskytovaly naprostě hojně - nejen v sw, ale i třeba v zaheslování BIOSu, nebi jinde. Byla jiná doba a nelze to tak úplně poměřovat dnešními měřítky.

Představte si, že v té době neexistovaly spamy, viry byly mnohem chytřejší, efektivnější a lépe naporgramovány, než dnes a dokonce dost často i něco ničily - ne jako dnes, kdy viry jsou víceméně jen obtěžující, ale většinou hodné. A kdy každý kdo dělal s počítačem nutně musel skoro vždy zvládat práci v příkazové řádce.

A o kousek dříve se ještě divili, jaktože může počítač vážit méně, než několik tun.

Zkrátka jiná doba...

[Michal Kubeček]

Měl jsem na mysli hlavně ten backdoor, ale nejen ten. V každém případě jsem myslel skutečně věcné chyby, rozhodně ne coding style.

[Miloslav Ponkrác]

Fajn fajn, tak až najdete bezchybný program, dejte mi vědět

[Kyosuke]

Chuck Moore prý nějaké píše. (Asi to bude kamarád Chucka Norrise... )

[Filip Jirsák]

Až najdete chybu v qmailu, dejte mi vědět

[ivan]

Neni qmail ten program, ktery ma napsany vlastni resolver? Ten ma omezeni na velikost odpovedi z DNS serveru na 512 bajtu. Pak staci pridat DNSSEC zaznamy a qmail je v ... Tohle samozrejme neni chyba autor to do programu vlozil umyslne a kazdej kdo pouziva digitalne podepsany DNS zaznamy je idiot. Uzivetele qmailu se s tim vetsinou nesetkaji, protoze na to existuje third-party patch, ktery pouziva kazda distribuce.

[Miloslav Ponkrác]

Až najdete chybu v qmailu, dejte mi vědět

Qmail bugs and wishlist

[Filip Jirsák]

Ale pořád jich je celkem málo, zatímco existují programy, kde je chyba snad na každém řádku. Takže tvrzení, že (téměř) každý program obsahuje chybu je sice pravdivé (protože dokázat, že program je bezchybný, není žádná legrace), ale v praxi jde spíš o to, jestli ten program je jedna chyba za druhou, nebo jestli je v něm těch chyb relativně málo.

[s0]

ad buzarace od komentátorů - na tohle se snad specializují středoevropané (východnějšího ražení) a Němci to opravdu nejsou. Kolikrát si říkám, že webové redakční systémy by měly mít nějaky filtr na automatické odstřelení československých komentářů.

[Petr Sigut]

Všichni jste tady borci na C++ a po tom co jste prolítli kódy firefoxu tak jste sproste psali na icq... super.

[Luboš Doležel (Doli)]

Moc pěkné:

Out of memory: kill process 13670 (mozilla-launche) score 297690 or a child
Killed process 13679 (firefox-bin)

Po tomhle zásahu byly 3GB RAM volné. Firefox běžel několik dnů.

[Kvakor]

Pokud uz dneska podporuje Firefox ulozeni stavu do "session" a restartnuti prohlizece, tak proc to nepouziji? Nevim, jak vypadaji vnitrnosti Firefoxu, ale dnes by prece nemel byt problem, aby kazdy tab bezel "z vlastni pameti" (jedno jak realizovano, stejne by to asi dost zaviselo na systemu, treba ve Windows se nespis /dev/zero nammap()ovat neda ) a pokud by nebyl aktivni a zacal by dochazet pamet, tak by se stav ulozil do session a prislusny tab/vlakno/proces by byl ukoncen a veskera jeho pamet dealokovana najednou.

Pokud by byl znova potreba, tak se znova "vzkrisi" z ulozenych dat, ktere by se samozdreme daly pouzit i pri restartu po padu prohlizece. Samozdrejme, objekty v cache (tj. stazene stranky, CSS, Javascript, obrazky, flashe a ostatni vlozene vselicos) by byly mimo tento prostor, pod nejakym cache-managerem, co by to mel sam na starost.

Navic by se tim daly lepe vytizit vicejadrove procesory (treba u mne ted Iceweasel (tj. debiani prebrandovany Firefox), zerouce 130MB, ma zrovna ted sedm vlaken a z toho ma jen dve nejaky spotrebovany cas) a snad i zvysit odolnost proti padu (padne jen jeden tab, ne cely prohlizec).

[Petr Tomeš]

Další podrobnosti o paměťové náročnosti Firefoxu a jak je neustále zlepšována: leaking, growing, and measuring

[kavol]

zlepšována ... tím se míní zvětšována?

[Petr Tomeš]

Tím se myslí to, že to byla vždy (a stále je) priorita a je jí věnována velká pozornost.

[Drom]

Tak uz by to mohlo prinest vysledky konecne :)

[Petr Tomeš]

No výsledky jsou průběžně a já je pozoruji. Nebo máte jen zapotřebí blbě pindat?