pouzivam Opera12 stale jako primarni... takze jo i na dnesnich strankach, kdy nepocitam nektere dnesni aplika(/sra)ckoweby (facebook, google+)... aktualne mi bezi:
Opera12 - 40 tabu ~900MB RAM - uptime 14dni
Chromium44 - 5 taby ~500MB RAM - uptime 5minut
5 tabu v Chromium jsou zkopirovane z Opera12, tedy ne ze sem tam otevrel nejake narocnejsi ;)
tak pulka tabu u Opery ma historii predchozich pro back + desitky tabu byli od pusteni otevreny a zavreny...
minimalne 2 :) ja kdyz zkusim jinej prohlizec tak se cejtim jak bezrukej :) obcas kouknu na Opera3x ale to je porad marne, Otter je bezva ale chce to cas, ale nejvice me potesil Vivaldi, pokud se $clanek podari a nebude to zavrene v Chrome, ale i v Chromium, dostane se to do Vivaldi, tak si ho jako primarni dokazu predstavit za 0.5? 1? rok :) zatim pouzivam Vivaldi jako secondary browser pro stranky co v Opera12 nejedou, nebo nekdy pustim na to Otter...
Taky jsem ještě v květnu na starém notebooku používal Operu 12, ale z jejich stránek se nedá stáhnout deb balíček pro starou Operu, tak zkouším tu novou, ale není to prostě ono:-(
Teď od srpna testuji Vivaldi a vypadá to dost použitelně, je to od lidí, co stáli u zrodu Opery a je to znát. Ale je to pořád ještě syrové a je vidět, že na tom musí odvést ještě hodně práce.
nevim co delas :) ale opera12 mi to nabidne kdyz vlezu na opera.com a tuknu download, je tam moznost zobrazit dalsi verze (Show other versions) kde je pak vyber ze "vsech" verzi od Opera11:
32bit: http://www.opera.com/download/guide/?os=linux-i386&list=all
64bit: http://www.opera.com/download/guide/?os=linux-x86-64&list=all
z toho dole pres "Opera archive" se dostanes dokonce k verzim od Opera5 ;)
http://arc.opera.com/pub/opera/linux/
no a nebo ciste pres repositar opery, si muzes nainstalovat Opera12 jednoduse balicekem opera :) protoze Opera3x je jako balicek opera-stable (nebo pripadne opera-developer) ...
http://deb.opera.com
Inu, milý kolemjdoucí, myslím, že by sis měl mechanismus swapování nejen nastudovat, ale hlavně si pořádně rozmyslet, jak může být efektivní. Vysypání všeho, co souvisí s otevřeným tabem, do souvisle uloženého souboru bude nejspíš řádově rychlejší než tohle všechno vyzobávat po stránkách a pak to zase ve víceméně náhodném pořadí natahovat. To vše včetně nesouvisejících dat, která se náhodou připletla do stejné stránky.
To samozřejmě nastudováno mám, víceméně náhodné swapování má statisticky lepší výsledky explicitní uložení do souboru a pak explicitní znovunačtení ze souboru, jakkoliv se to laicky zdá opačně, dále tato explicitní práce se soubory poškodí diskovou cache, takže situace je o to horší.
Je to proto že prohlížeč nezná budoucnost, nezná budoucí činnost uživatele, neví zda za 30 minut klikne na tab nebo spustí Office.
On to asi myslel prave tak, ze pristup ke swapu neni nahodny, ale pristup ke konkretni strance pameti na disku ano. Pro lidi co nemaji SSD disk to muze byt problem a pride mi, ze casto je rychlejsi natahnout 100 objektu o celkove velikosti 1MB znovu, nez vubec nejakou diskovou cache mit a nebo prepnout na nejakou zalozku po te co byl system uspan.
Nevim jak to vidis ty, ale ja bych teda swapoval vse, co se nepouziva, a zaroven to nechaval v RAMce, dokud tu RAMku neporebuje neco dalsiho. Ale trebas jsou implementatori swapu proste tupci.
Tzn, RAMka by byla k dizpozici, ale zaroven by v zavislosti na jeji velikosti bylo v te RAmce prakticky vse co treba i pokud se to zrovna nepouziva.
Problem browseru je totiz predevsim v tom, ze RAM neuvolnujou, a "spravu" si resej ve vlastni rezii. A to rozhodne neni nejaky nahodny cteni neceho z disku, to je pomerne sofistikovanej pristup, ktere dava slusnou efektivitu a pravdepodonost, ze se neco z toho disku vubec cist bude, je velice nizka. Narozdil od pristupu, ze to na disk ulozim vynucene. A pak to z nej budu samosebou cist ve 100% pripadu.
SSD je porad o nejaky ty rady pomalejsi nez RAMka.
Swapovat vše – to by určitě šlo a zrychlilo by to odkládání do swapu. Ale ne zadarmo: Vytvořilo by to I/O aktivitu, která není zadarmo (stojí energii, u HDD hluk, u SSD omezené přepisovací cykly). Zpomalovat stroj by prakticky nemusela, když by to mělo vhodnou prioritu. Osobně bych to na svém notebooku asi nechtěl – virtuální stroje se mi dělí o 16GiB RAM, ale swap (pokud na něj náhodou dojde, typicky kvůli paměťovému limitu) je na HDD.
SSD – pokud srovnáme swapování se suspendováním panelů, tak zmínka o SSD je na místě. Na HDD swapování nepoužívaných panelů nebude efektivní, protože se bude odswapovávat chaoticky a podobně chaoticky se bude i číst ze swapu. Celistvé odklizení jednoho tabu bude efektivnější. Naopak, na SSD by to mělo být srovnatelně rychlé. (Předpokládám, že jak swap, tak odkladiště tabů, je obojí buď na SSD, nebo obojí na HDD. Vím, nemusí tomu tak být, ale pak je to srovnání jablek a hrušek.)
Agresivně odkládat stránky do page file je dobré, pokud je málo RAM. Ale není moudré odkládat vše, protože při jakékoliv operaci v RAM byste změny okamžitě přepisoval na disk. Navíc když je spousta volné RAM (mnohonásobek běžného požadavku na alokaci), tak je swapování celkem zbytečné. Swapovat ano, ale všeho s mírou.
Ad swapování nepoužívaných panelů nebude efektivní - proč by nemělo být?
Ad podobně chaoticky se bude i číst ze swapu - tomu můžete triviálně pomoc tím že stránky označíte pomocí VirtualLock(), kernel je pak ASAP dostane z page file do RAM. Pokud by to nefungovalo, můžete na každou požadovanou stránku sáhnout (nejlépe separátním threadem) a tím způsobit page fault, který stránku dotáhne. Dokonce můžete ovlivnit pořadí, ve kterém stránky budete natahovat.
As swapování nepoužívaných panelů nebude efektivní – myslel jsem klasické swapování (a bylo to v kontextu HDD). Jde o to, že to swapování neproběhne souvisle a přečtení ze swapu taky ne. Což udělá random I/O, což je na HDD problém.
Ad čtení ze swapu – ideálně bych ale z něj chtěl číst v pořadí, jak je to uloženo na disku (což ví OS, ne aplikace), ne v pořadí, jak jdou adresy ve virtuální paměti. Sahání na stránky se mi tedy nejeví jako moc efektivní, protože nevím správné pořadí. Možná to udělá ten VirtualLock, nevím.
Když jsem mluvil o náhodnosti, nemyslel jsem, že by kernel swapoval na základě náhodné volby stránek, ale že rozložení přístupů na disk způsobených swapováním se bude chovat dost náhodně se všemi nevýhodami, které z toho plynou.
Jistě že by bylo pěkné navrhnout swapovací algoritmus, který by se takhle nechoval, ale to se zatím nikomu nepovedlo (tedy pokud pominu strategie typu "odswapuj celý proces" přítomné na raných Unixech, které zase měly jiné nevýhody). Na prakticky jakémkoliv OS dneska jednoduché měření ukáže, že swapování je strašlivě neefektivní. [Zejména pokud mluvíme o klasických discích -- na SSD je situace o něco lepší.]
Další problém, na který není radno zapomínat, je, že kernel má od hardwaru jen velmi kusé informace o tom, na které stránky se kdy přistupuje (v zásadě jen jediný bit "přistoupilo se od poslední kontroly stránky"). Skutečná implementace swapování má tedy k nějakému ideálnímu LRU na míle daleko.
Konec konců, stačí si zkusit Chrome nebo Firefox spustit na stroji s 256 MB RAM a spoustou swapu, pootevírat pár tabů a pak si krátit čekání pohledem na zběsile blikající diskovou LEDku ;-)
Netreba zachazet do extremu ... staci si FF spustit v jeho 64bit variante .. a skoro bych rekl ze na libovolnem stroji. Za 3 dny mi nabobtnal na 6GB ... a nevypadal ze by chtel prestat. Jelikoz mel stroj jen 8GB ram, tak jsem jej na zaklade tohoto chovani terminoval jako zcela nepouztelny kram.
Mozna by ke stesti stacilo, proste browseru poslat fake, ze zadna dalsi RAM proste neni a nebude. Idealne nejak snadno uzivatelsky. Proste donutit system, aby mu zadnou dalsi nedal.
Skoda ze jeste nejsem sklerotik ... a pamatuju doby, kdy vecem stacily kB ram a MHz CPU. Na disketu se pak vesly stovky aplikaci.
Tak na to oznameni, ze dalsi pamet neni, by browser nejspis zareagoval jako vetsina ostatnich programu: sel by do kytek - v pripade chromu mozna jen ten tab, ktery si jako posledni o pamet rekl. Prave predpoklad, ze pamet je "neomezena" z pohledu programatora, umoznuje psat programy vyrazne rychleji, a vetsina programatoru vubec neosetruje stav, kdy malloc vrati NULL. On kernel stejne nekdy ten NULL nevrati (treba proto, ze mu jeste trochu pameti zbyva) a nasledne vyvola OOM killer (treba proto, ze tu pamet najednou potrebuje na neco kernel samotny). Navic jakakoliv slozitejsi heuristika v alokacnim kodu kernelu se muze draze nevyplatit na vykonu.
A jeste k tomu swapovani - pokud se udela spravne aplikacni swapovani, tak se serializuje pouze /obsah/ stranky (tj. neco jako zdrojovy kod stranky) a ten se vymrskne na disk. Tedy treba o takovem divu budes mit jen zakladni informaci (v extremnim pripade treba jen uzel v dom stromu), misto toho, abys znal vsechny informace o tom jak je zrovna vyrenderovany na strance (tedy jeho aktualni pozici a velikost, barvu, velikost okraju a spoutu dalsich veci, ktere /ziva/ stranka potrebuje).
To nevím o kom mluvíte, ale mě třeba při nedostatku paměti vyskakuje výjimka OutOfMemoryException (výjimka v mé C++ knihovně). Postihnutý jsou veškeré alokace. Výjimka často pomůže, protože při následném stack unwindu se zpravidla uvolní nějaká další paměť.
V tom problém není. Tohle totiž řeší pouze chyby alokace nad rámec overcommitu. Jenže paměť zpravidla dochází mnohem dříve a pak takové procesy zabíjí OOM killer proti němuž není žádná obrana.
Nikoliv. To o čem mluvíte je vlastní alokátor (respektive wrapper alokace), ten může v případě chyby zkusit uvolnit paměť (aby mu jí sežral jiný program), zkusit alokaci znova a potom teprve vyhlásit chybu (výjimku). Jakmile je výjimka vyhozena, tak už poslední alokace _selhala_, a musíme se obejít _bez_ ní. (Což v případě, že to je třeba zvětšení struktury udržující DOM, znamená, že jde celý tab do kytek.)
To je sice hezke, nicmene nevim, jak chces odswapovat bezici proces. Ze swapu ti nepobezi. Otevri si v tom Chrome zazraku par tabu, pockej, az se dukladne naloaduji a otevri si ten jejich task manager. Uvidis, ze rada stranek periodicky neco dela, i kdyz na ne necumis. Obcas vybehne CPU a obcas nektere i hrabnou na sit. Cili ten proces se tam jen tak nevali, aby se dal narvat do swapu, ale bezi. A ted je otazka, kolik pameti si necha odswapovat a kolika se bude porad domahat zpet. Pokud by to treba vyslo tak, ze kazdemu procesu lze odswapovat treba i 10% pameti, tak to snad ani za to usili nestoji, to nikoho moc nevytrhne. Na to, aby to slo dukladne odswapovat, by Chrome musel kazdy proces tabu, na ktery necumim, po nejake dobe zastavit, coz ocividne nedela.
ses natvrdlej? :) OS nemuze vedet jestli jsou taby delsi dobu TEBOU nepouzivane, pokud si zijou vlastnim zivotem, prohlizec nezna budoucnost, ale nezna ji ani OS, jenomze narozdil od nej, zna prohlizec minulost a soucastnost tabu a to jestl a jak dlouho si ktere taby kdy prohlizel...
Přesto nevidím důvod dělat to na úrovni browseru. Když browser tab "odswapuje" ve vlastním formátu, samozřejmě se zastaví skripty které na tabu běží. Proč tedy prostě nezastavit thread nebo proces daného tabu a nenechat příslušné stránky odswapovat na úrovni OS? Pokud uživatel přepne zpátky na daný tab, přijde thradu i procesu event, rozběhne se, a stránky paměti se prostě dotáhnou ze swapu.
Samozřejmě serializace kompletního stavu tabu je dobrá myšlenka. Hodí se to například pro znovu-otevření zavřeného tabu.
V tomto musím souhlasit.
Pokud běží tab jako vlákno nebo proces, není problém poslat mu zprávu / signál a hodit do suspend a uklidit. A klidně se to může udělat na základě toho, že uživatel nerozklikl nějakou dobu záložku (počítám, že streamování rádia dostane v pluginu vlastní vlákno, který se neuspí).
Pokud by swap tabu zabral i s režií 10% výkonu stroje po dobu 100ms a jinak by 20 uspaných a odswapovaných tabů žralo trvale po 2% jednoho jádra, je to sakra rozdíl. Takže přínos to bude.
Ale serializace? Co to přinese? Režii navíc, navíc řešení uklízení v rámci prohlížeče znamená i kód a bugy navíc... Pokud je možnost říct "hele systéme, RAMku proxesu X od adresy Y do adresy Z teď nebudu potřebovat..." Snad jenom pokud si ti exoti vytvoří interně v procesu vlastní heap větší, než data tabu...
Protože kdykoliv aplikace fušuje do činnosti OS tak to dopadne špatně, výjimkou jsou DB servery. Správné chování aplikace je alokovat přesně tolik paměti kolik potřebuje, žádné syslení RAM do zásoby a o tom zda se nějaká paměť bude swapovat nebo nebude si OS rozhodne sám.
alokovat přesně tolik paměti kolik potřebuje
Kolik to je? Třeba zrovna u webového prohlížeče? Je to paměť potřebná na vykreslení viditelné části stránky? Nebo paměť potřebná na vykreslení celé stránky? Nebo i paměť uchovávající předchozí stránku, aby návrat zpět byl rychlý? Problém je v tom, že dělení potřebná/nepotřebná je příliš hrubé - program často dokáže rozumně využít víc paměti, pokud je k dispozici, ale dokáže se bez ní obejít, pokud začne být paměti málo. Proto se řeší, jak dát programům vědět, že paměť dochází a měly by se uskrovnit.
Tohle měl kdysi docela hezky vyřešené AmigaOS, ostatně jako ledacos. Škoda ho :)
Mimochodem, viděl jste už nějaký konkrétní návrh podobného mechanismu pro Linux? (Ono to bohužel není triviální, protože se musí notifikace o nedostatku paměti distribuovat v dostatečném předstihu, aby na jejich zpracování ještě byla paměť a nebyly z ní vyhozené kusy kódu, které se mají o obsluhu postarat.)
i kdyz predpokladam ze mluvis o 3.x pro/na m68k, tak AmigaOS 4.1 vysel ani ne pred rokem ;)
Jj, AIX má SIGDANGER. Předalokování místa ve swapu bylo zrušeno v AIXu 5.1 (rok 2001).
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.baseadmn/doc/baseadmndita/page_space_trouble.htm
Ad Donedavna to umelo jen odwapovavat cele soubory - to by mě dost překvapilo. Máte k tomu nějaké další informace?
Aha. Mate pravdu, uz delsi dobu jsem si svoje informace neaktualizoval. Pamatuju si, ze kompilace zdrojaku na AIXu anebo servirovani statickych stranek na Apache byval problem. Bylo to pomaly. Prave proto, ze cachovani na AIXu byvalo mnohem jednodussi nez na Linuxu (na druhou stranu to vzdy bylo i stabilnejsi).
PS: Linux ma (narozdil od Unixu) moznost pri zavolani signalu predat i nejake parametry handleru. Napr. SIGCHILD predava PID procesu.
U Apache na AIXu býval velký problém s multithreadingem, protože multithreading na AIXu měl dost mizerný výkon. Solaris na tom naopak byl podobně jako Windows řady NT. Dnešní situaci neznám.
Ad Linux ma (narozdil od Unixu) moznost pri zavolani signalu predat i nejake parametry handleru - to je praktické, ale chtělo by zahrnout do POSIXu. Ono z hlediska programátora pro UNIX jako platformu není dobré, když se API jednotlivých implementací příliš liší.
Myslím, že byly nějaké pokusy zavést volatilní rozsahy paměti nebo madvise()
(tj. označit paměť tak, že ji jádro může v případě potřeby zahodit). Shrinker
umožňuje informovat o nedostatku paměti subsystémy jádra, ale zatím myslím není shoda na tom, jak to propagovat dál do uživatelského prostoru – právě z důvodů, které uvádíte.
Ad není shoda na tom, jak to propagovat dál do uživatelského prostoru - stačí se podívat třeba na AIX. Má dva prahy: pokud se dostanete pod paging-space warning level, začne posílat SIGDANGER. Pokud se dostanete pod paging-space kill level, začne odstřelovat procesy které nemají handler pro SIGDANGER. Vyjma toho aplikace mohou voláním psdanger() zjistit rozdíl mezi aktuální volnou pamětí a prahy paging-space warning level a paging-space kill level. A dá se nastavit, že pokud není dost paměti ani po odstřelení procesů bez SIGDANGER handleru, tak se začnou odstřelovat nejmladší procesy které handler mají.
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.genprogc/paging_space_prg_req.htm
Samozřejmě to není dokonalé, protože Memory Overcommitment je v principu špatný nápad.
http://www.oracle.com/technetwork/server-storage/solaris10/subprocess-136439.html
Samozřejmě to není dokonalé, protože Memory Overcommitment je v principu špatný nápad.
Myslím, že tady jde trochu o něco jiného. Je rozumné využít paměť, když je jí spousta a je jí dost - ostatně tu spoustu přebytečné paměti do počítačů kupujeme proto, aby se rozumně využila, ne proto, abychom se kochali, že je 70 % paměti volné a připravené pro použití "co kdyby náhodou". Tohle má řešit případy, kdy najednou z nějakého důvodu zpravidla krátkodobě nelze pamětí plýtvat a proces by se měl uskrovnit.
Overcommitment na Linuxu měl primárně řešit situaci, kdy proces tvrdí že potřebuje spoustu paměti, ale ve skutečnosti ji nepotřebuje. Typickým příkladem je fork-exec. Problém je v tom, že kdy slíbíte procesu paměť kterou nemáte, a pak se se té paměti nedostává, tak nemáte jak to procesu říci, a je potřeba něco odstřelit (OOM Killer). Navíc to vede k situaci, kdy se autoři aplikací ani neobtěžují řešit to že alokace paměti selže, protože ta na Linuxu až na extrémní případy vždy projde, a pak je někdo bez varování odstřelen. Vizte výše ten link na Oracle, je to tam pěkně vysvětlené. Implementace "uskrovnění" paměťových nároků procesů je slabá náplast. Lepší než nic, ale chtělo by to alespoň něco takového na Linuxu implementovat. Pokud možno ne moc odlišně od stávajících implementací, protože pro autory aplikací je roztříštěnost UNIXů (nemluvě o distrech Linuxu) už tak dost velká zátěž.
To je tolik kolik aplikace skutečně na něco využívá využívá, žádný garbage collector, prealokování paměti do zásoby, nevracení již alokovaných bloků zpět OS a podobně. Problém není že si aplikace nacacheuje 10 webových stránek do RAM, ale že si jen tak preventivně nasyslí 50 MB pro každý tab.
btw. Stránka natahá cca 5 MB z internetu, vykreslená bitmapa cca 800*3000px má pouhých 10 MB, tak proč do pr*** celý tab žere 100 MB ?
Ad Stránka natahá cca 5 MB z internetu, vykreslená bitmapa cca 800*3000px má pouhých 10 MB, tak proč do pr*** celý tab žere 100 MB - na prvním místě potřebujete executable jako takový. Potom musíte HTML nacpat do paměťových struktur umožňujících random access. DOM potřebuje cca 10x více paměti než zdrojové HTML. Nevím jestli se informace o vizuálních objektech skladují v DOM nebo zvlášť, ale ty objekty mají spoustu vlastností které nejsou v zdrojáku stránky (všechny properties které jsou podporované ale nejsou uvedené na stránce), nebo nejsou vůbec součástí HTML (například informace o zlomu textu), a určitě to také strojí dost paměti. K tomu většina stránek obsahuje skripty, což znamená izolovanou instanci nějakého JS engine, který dneska typicky obsahuje i nějaký kompilátor. Pak musíte vyrastrovat všechny prvky na stránce, některé vícekrát (například animované gify).
Jo a koukal jsem kolik si vezmou procesy MSIE a Firefoxu.
MSIE (process-per-tab):
- Base process 9MB
- Tab http://www.msftncsi.com/ncsi.txt 10MB
- Tab http://www.idnes.cz/ 42MB + 3MB proces Adobe Flashe
Firefox (single process):
-Tab s http://www.msftncsi.com/ncsi.txt 116MB
- Když přidám tab s idnes.cz tak 160MB + 9,5MB dva procesy Adobe Flashe (nevím proč dva).
V obou případech jsou browsery bez doplňků, Chrome nemám. Řekněme že Firefox nejspíš není úplně vzor úspornosti.
Obecněji je problém v tom, že se snažíme z webového browseru za použití hromady skriptů dělat aplikační platformu. Sice webové aplikace pořád nedokážou to co desktopové aplikace před dvaceti lety, ale náročnost na RAM a CPU je už dávno nesrovnatelně vyšší.
Pokud bychom to odswapování na vlastní žádost chtěli řešit per-thread a chtěli bychom do toho zahrnout i heap, máme problém s tím, že thread nemá svůj vlastní heap. Má heap sdílený s ostatními vlákny, z nichž některé možná nemají být odswapovány. Takže by se muselo řešit, kterou část heapu odswapovat. Asi projít všecno relevantní a nějak to označkovat, ale přitom neoznačkovat nic společného. Navíc informace v heapu by mohly být trošku promíchány (v rámci jedné stránky se budou míchat aktivní i neaktivní data), takže bez defragmentace (heap compaction) by se těžko něco uklízelo.
Nevím, jestli má v Chrome skutečně každý tab vlastní proces, nebo jestli to je per-domain, nebo jak to přesně je. Ale každopádně, pokud by to odklízení mělo být jinak než per-process, dost by se to tou spoluprací s OSem zkomplikovalo (nebo aspoň nezjednodušilo).
Druhá věc je, že nevím, jestli takovéto možnosti vůbec nějaký OS nabízí. I to může být důvod pro vlastní řešení.
Řešil bych to per-page, nikoliv per-thread/process. Když thread/process čeká na událost, nesahá na svá data v heapu. Tyto stránky jsou pak LRU, a kernel je zkopíruje do page file. Pokud paměť potřebuje jiná aplikace, tak kernel odloženou stránku přidělí té aplikaci namísto browseru. Navíc jediná změna potřebná na straně browseru je zastavení threadu/procesu, který se o tab stará.
U thread-per-tab modelu samozřejmě v heapu mohou být skončit informace z různých tabů v jedné page. To ale asi bude poměrně výjimečné. Podle nějakého článku na zive.cz (link v diskusi níže) si FF řekne o 50MB RAM jen pro renderer. Tahle paměť, stejně jako DOM, bude poměrně souvislá.
Per-page – jenže tím se dostáváme k něčemu podobnému, jako je klasické swapování. Včetně nevýhody v podobě hromady random I/O. (Předpokládám, že tím „page“ myslíte stránku paměti, ne webovou stránku.)
Thread-per-tab – s tím si nejsem až tak jistý. Záleží taky na alokátoru, ale pokud se budou mixovat alokace jednotlivých vláken, tak to, zvlášť u dynamických stránek, až tak souvislé být nemusí.
Jinak ani si nejsem jistý, jestli thread-per-tab je vhodný model. Na některé věci (napadá mě I/O) by stačilo jedno společné vlákno. Na řešení událostí, no, to je dost otázka.
Ad se dostáváme k něčemu podobnému, jako je klasické swapování - ono to je klasické swapování, modifikované jen tím že když tab není nějakou dobu na popředí, tak se zastaví. Se zbytkem si poradí OS.
Ad pokud se budou mixovat alokace jednotlivých vláken, tak to, zvlášť u dynamických stránek, až tak souvislé být nemusí - samozřejmě to není 100% čistý řez, ale to ani není potřeba.
Ad jestli thread-per-tab je vhodný model. Na některé věci (napadá mě I/O) by stačilo jedno společné vlákno. Na řešení událostí, no, to je dost otázka - zrovna I/O musí být řešené multithreadově/asynchronně. Jinak se vám jeden request sekne čekáním na timeout, a všechno kvůli tomu bude stát. Podobně rastrování musí být multithreadové. Jinak se vám na jednom tabu bude pomalu rastrovat stránka plná čínského textu, a všechno ostatní kvůli tomu bude stát.
„Jinak se vám jeden request sekne čekáním na timeout, a všechno kvůli tomu bude stát.“ – Mělo by to být asynchronní, ale ne nutně multithreadové. Jedno jádro dávno zvládne obsloužit I/O a u toho se flákat.
„Podobně rastrování musí být multithreadové. Jinak se vám na jednom tabu bude pomalu rastrovat stránka plná čínského textu, a všechno ostatní kvůli tomu bude stát.“ – Nepopírám. Ale to neznamená thread-per tab. Dovedu si představit thread pool (o velikosti podle počtu jader), který by řešil výpočetně náročné úlohy. Muselo by se to ale udělat tak, aby se nestalo, že jeden tab si zabere dlouhou dobu v thread poolu a na ostatní nezbyde nic.
Tato funkce se mi hrubě nelíbí a doufám, že ji neodkoukají i vývojáři Firefoxu. Pokud se po obnovení tabu něco načítá, je to průšvih, protože mohou z různých důvodů přijít úplně jiná data a stránka bude nekonzistentní. Ani při uložení na disk a následném obnovení to ale nemusí být úplně bez problémů, u některých webových aplikací mohou například vypršet timeouty apod. Prohlížeč by neměl "chytračit" a montovat se uživateli do toho, jakým způsobem pracuje.
taky by prohlizec nemel byt pametove narocnejsi nez rendrovani 3D celoveceraku ;)
kdyz si aktualne hybernujes celej system s nabehnutym prohlizecem je to ted problem po probuzeni s nekonzistetnima webama? neni co :) tak proc by musel byt problem s hybernaci samostatneho procesu/tabu primo prohlizecem?
rozhodne je to jedna z klicovejch vlastnosti co by dnesni prohlizec mel mit (pokud teda uz nedokaze byt tak uspornej jako Opera12/Presto)
> je to ted problem po probuzeni s nekonzistetnima webama? neni co :)
Vy ho nemate, nekdo ho treba ma. Hibernaci nepouzivam, ale zato se mi nejednou stalo, ze po rucnim sestreleni nebo padu prohlizece a nasledne obnove session se nektery ze starsich tabu nenacetl, protoze ta stranka na serveru uz neexistuje, nebo neexistuje ani ten server (trvale nebo docasne). Taky s dokumenty nactenymi metodou POST muze byt problem (i kdyz to vetsina webu uz miva osetreno). A nebo proste nechci, aby polovina smiraku na Internetu byla informovana o tom, ze jsem se na ten tab prave znova prepnul podle toho, ze se dela jeho reload.
1. Jakmile přijde tab serializer, tyto problémy nebudou. Nevím, jestli se tato funkcionalita dostane do ostré verze bez tab serializeru.
2. Pokud někdo chce zjistit, že jste přepnul na jeho stránku, může to zjistit už dnes mnoha způsoby. Tuším, že okno má nějaké onfocus/onblur (nedělal jsem s tím, ale matně si na to vzpomínám) a dokonce i nějaké speciální události typu „není na mě vidět“. A i kdyby tu nic takového nebylo, jsou tu události jako keydown a mousemove, z nichž nějakou nejspíše vyvoláte. Ne, šmíráci nedostanou prakticky nic navíc, pokud vůbec něco.
Data se schovají 1:1 jako při uspání systému. Pokud se periodicky načítá, je to obvykle děláno JavaScriptem. Ten prostě dosatne zprávu, že je o X sekund pozděj, než se zastavil a může se refreshnout.
Pokud stránka potřebuje "pinkat" po třeba pěti minutách, aby nevyprčel session timeout, tak je to problém na straně autora. Nebo bezpečnostní funkce, třeba v bance. Chová se to zase stejně, jako když vypadne lajna, nebo uspíš kompl.
Ušetří výkon CPU s renderováním tabů, na který nekoukám. Ušetří kapacitu lajny na update tabů, na který momentálně nekoukám. Ušetří RAMku, protože v ní nedrží data, na který nekoukám. Ušetří často i disk, protože jednou uloží tab a pak po dlouhé době zase načte, místo aby po něm štrachal furt podle toho, jak se načítají a uvolňují pluginy, probíhá refresh dat a potřebuje je házert do lokální cache,...
Kde je, sakra, problém?
Nechapem preco toto Google v Chrome riesi pod vlastnou reziou. Ako tu bolo spomenute, ked dochadza pamet tak to ma riesit a ma to na starosti OS. Su urcite specificke pripady kedy je lepsie ked si to aplikacia manazuje sama vo vlastnej rezii ale nemam pocit ze zrovna browser by mal do tej kategorie spadat. Uplne by stacilo keby korektne uvolnoval pamet a oznacoval nepotrebnu (aktualne nepouzivanu?) pamet pre os ze ju moze swapnut ak treba (netusim ci je taka funkcionalita pre vecsinu os alebo memory manager sam si pozera ktore stranky su ako vyuzite a v pripade potreby ich swapne).
Hele, kdyz si pustim 90% soucasnych games, vpohode se i ty nejnarocnejsi spokojej s 2GB RAM. Stale jich drtiva vetsina bezi ve 32bitech. Kdyz zacnu strihat video, dostanu se pres ty 2GB vyjimecne.
Vysvetli mi, proc debilni prohlizec textu (a ano, bude se to tak chovat, i pokud vypnes js, vypnes obrazky ...) vyzaduje gigabajty RAM? To nema s OS nic spolecnyho. A tohle je pochopitelne taky zcela knicemu, protoze ty browsery tu RAMku predevsi v prubehu sve cinnosti neuvolnujou, a to tak ze nikdy. To si ostatne muze kdokoli vyzkouset. Otevri si 200 tabu, at to dostane poradnou davku dat, a pak je vsechnny krom posledniho zavri ... a zjistis, ze to porad zere presne stejne.
Podle toho co tam píší, tak to uvolňování paměti z RAM a odsouvání do cache, případně do swapu je asi dobrá cesta. Bude záležet na implementaci, určitě asi není důvod, aby článek nebo postup, který jste si našli ráno a prověřujete další možnosti, byl ještě po obědě pořád v RAMce a když se pak vrátíte, načtení kdyby 2s někde z disku, to se snad nikdo nezblázní. Pokud se to pak nebude muset ručně promazávat na disku, něco jako flash .macromedia ;.)
Otázka ale taky je, jestli někdo, kdo má 4G RAM a otevřené IDE, nějaké podklady, PDFka, Office, hudbu, 5 dodívaných videí na portálu, 3 prohlížeče s adminerem, xmlkama, 50 tabů ..... za celý den se to může naskládat, by se neměl zamyslet nad rozšířením RAM.
No nevim jake mate zkusenosti vy, ale pro me vetsina veci nefunguje automaticky dle ocekavani, takze je casto vypinam. Nemam rad, kdyz chce byt pocitact "chytrejsi" nez uzivatel. Uz vidim, jak se chrome rozhodne zavrit tab s IRC, protoze ho pul dne neotevru hmmm a pak co? Stranka si bude urcovat jestli teda muze byt zavrena nebo ne? Hmm pak bude nejaky plugin, co to bude vypinat? No jeste stesti, ze mi chrome proste na pocitac uz nemuze, dostalo ban.
presne tak, napr. jako to ma ten v clanku zminenej doplnek "The Great Suspender"... urcite bude lepsi takovou funkci implementovat interne primo v browseru, Chrome(ium) sice nepouzivam, ale bude se to hodit ve Vivaldi kde teda aspon mam pokusne ten GreatSuspender ;)
Nieje clanok na zive.cz nahodov skopceny s roota je az moc podobny http://www.zive.cz/bleskovky/chrome-chce-usetrit-vice-ram-a-bude-zabijet-stare-zalozky-zatim-to-skripe/sc-4-a-179534/default.aspx
Tabů nemám víc než 10, pokud ano, tak přebytečné sám pozavírám.
Kde ovšem vidím velké místo pro zlepšení je doba kompilace. Na gentoo mám firefox za 30 minut, chromium za 3 hodiny. Asi to kompiluje x knihoven znovu a samo pro sebe, ale stejně - rozdíl s faktorem 6, přičemž ve funkcionalitě zásadní rozdíly nejsou? Takové nějaké podivné mně to přijde.
[podobně nechápu, proč je potřeba se přihlašovat do google play, když chce člověk jen stáhnout aktualizaci např. prohlížeče - proč to prostě není volně přístupný repozitář? - ale to by bylo na samostatnou diskuzi]