Zkousel jsem oboji a je to opravdova hruza jak jedno tak druhe.
Ve svete browseru pro Linux se uz opravdu moc a moc tesim na OPERU.
Jestlize pro prohlizeni internetu potrebuji 350Mh procesor 160MB pameti tak to at se jdou programatori techto produktu bodnout.
Proc hruza a proc 160 MiB? Mam ted par dni stary nocni build Mozilly a nespadl mi jeste ani jednou (asi dvakrat vytuhlo okno, ale slo ho zavrit bez nasledku pro ostatni otevrena okna). Za cely den brouzdani zabira Mozilla v pameti 35 MiB, coz je sice hodne, ale na to, ze Mozilla obsahuje stale jeste spoustu balastu pro ladeni a take staticky linkovane Gtk, to povazuji za snesitelne. Communicator by mel uz tak kolem 60 a vice MiB a nebo by davno kleknul.
A pouzijete-li misto prostredi Mozilly zde zminene programy Skipstone nebo Galeon, pametove naroky i naroky na CPU opet o neco klesnou.
Tohle není ani tak odpověď jako spíš otázka... Je to "bobtnání" Netscape(u) či Mozilly způsobeno něčím co se nazývá $SUBJ? Tedy že v paměti zůstávají nedealokovaná data...
Mohl by mi prosím někdo jako laikovi vysvětlit, proč se už při návrhu aplikace neošetří tyto situace?
Jo to je problem toho ze netscape je jednovlaknovy (nedela fork) a alokuje pamet jak potrebuje - kdyz se zavre okno, tak on tu pamet MOZNA dealokuje ale hlavne ty dealokovane mista pameti jsou na strankach, ktere jsou prolezle jinou alokovanou pameti a tudiz se ty stranky nevrati operacnimu systemu. Bobtna a bobtna....
uz mel nekdo 160 MB netscapa? ja jo.... Stejny problem ma i X server, alokuje pamet pro ruzna okna a kdyz se ty okna zaviraji ma stranky v pameti prostrileny srznaskrz pameti alokovanou pro kdeco. Taky uz jsem mel 80MB Xserver. Je to proste o te alokaci a dealokaci pameti v libc pripadne malloc. Melo by se to udelat tak, aby ten alokator daval data pro jedno okno napriklad jinam nez pro jine okno, aby se to pri dealokaci nemixovalo. Nebo by se mozna radsi mel netscape forkovat a bylo by.
