Názory k článku Softwarová sklizeň (12. 2. 2025): prozkoumejte hvězdnou oblohu na terminálu

Viděl jsem různé testy a měření... jen mi to nikdy nestálo za to přecházet na jiný emulátor terminálu. Jinak velká část té latence nesouvisí s terminálem, ale s X11 nebo Waylandem (ten z toho vycházel ještě hůř než X11, co jsem viděl naposledy), ovladači a hardwarem.

A pro srovnání: za 100 ms zvládne databáze vykonat složitější SQL dotaz (ty jednoduché jsou pod 1 ms). A za 15 ms pingnu server kdesi v internetu.

Dnešní desktopy jsou hodně neefektivní.

Když se někomu povede optimalizovat emulátor terminálu, tak fajn, nic proti tomu, neuškodí to. Ale je dobré ty věci vidět v kontextu – když se podívám, kolik RAM a výkonu CPU propálí webové prohlížeče (a aplikace nad Electronem), tak řešit nějaký blikající kurzor v terminálu je poněkud úsměvné. Firefox, Thunderbird, Chromium – tohle je největší problém, stačí se podívat, kolik který program žere zdrojů. Často je tyhle procesy lepší odstřelit nebo jim poslat signál STOP a následně je probudit pomocí CONT, až když jsou zase potřeba, aby mezi tím nemohly škodit. Mám se trápit tím, co spotřebuje Konsole? Mám to optimalizovat? Možná až bude uspokojivě vyřešen problém nenažraných webů a prohlížečů (nebo až se jich zbavíme, ale to jen tak nebude).

Co se týče zátěže CPU a GPU (a následně třeba výdrže na baterku) - lidi si na to různě stěžují – např.:

https://github.com/kovidgoyal/kitty/issues/115
https://github.com/kovidgoyal/kitty/issues/7210
https://github.com/ghostty-org/ghostty/discussions/5031

Ono totiž nejde mít oboje (nízké latence a zároveň nízkou spotřebu). Sám autor Kitty k tomu např. píše:

I optimized a couple of code paths, thanks to the instrumentation, but fundamentally, I dont think CPU utilisation can be significantly reduced without compromising on other design goals. The reasons are:

1) kitty renders in a separate thread, this means that screen updates are processed at 100 FPS continuously. This involves serializing data to send to the GPU at 100FPS. This greatly reduces perceived latency, at the cost of higher CPU utilisation.

Tenhle přístup je vhodný pro hry (hra je v tu chvíli jediná aplikace, která mne zajímá, chci maximální výkon, maximální fps a vše ostatní jde stranou). Ale pro aplikace je to přinejmenším diskutabilní. (osobním preferencím se samozřejmě meze nekladou)

Ale zpět k původnímu tématu. Když už se má pálit výkon CPU a GPU, tak očekávám, že program bude mít hezký grafický výstup, aspoň na úrovni her z roku 1994, a ne jen text.

když se podívám, kolik RAM a výkonu CPU propálí webové prohlížeče (a aplikace nad Electronem)

Schválně, kolik?

Appku s Electronem co tak vím používám jen jednu a to je VS Code (i když možná i Spotify). Od prvního použití je to bleskově rychlé, před těmi lety jsem tím v podstatě nahradil notepad na widlích a na linuxu opustil svůj vlastně nikdy ne moc funkční setup na terminálu a vimu (v zásadě je to neúspěšný pokus se rozhodnout mezi tím, jestli stačí pouze syntax highlinting, nebo se hodí mít celé IDE, to IDE se mi ve vimu ani pro python, ani pro golang nikdy nepodařilo uspokojivě nastavit). Potom v nějaké diskusi (pochopitelně na českém webu) jsem se dozvěděl, že code je extrémně pomalé a žravé, protože je to v Electronu. Jako WTF?

Trochu mi to přijde jako ekvivalent povídaček o nenažranosti javy.

stačí se podívat, kolik který program žere zdrojů

To je trochu záludná metrika, protože kdybych svých několik desítek tabů převedl do nativních programů, tak to jednak nejde, protože ty programy nejsou k disposici, ale tak nějak obecně pochybuju, že by to bylo nějak výrazně méně žravé.

VS Code

Trochu to ulehčím, ať se máme o čem hádat. :-) Pustil jsem Code na W11, studený start do 0.5s i se všema extensions, code má nevím proč 11 procesů, celkem 460MB (ne giga nebo tera, mega!), největší code proces má 145MB a gopls (language server pro golang) si po očuchání mého projektu vzal 180MB. Takže v IDE pro golang je nejžravější právě golang language server.

Opravdu má další diskuse smysl?

Narážel jsem primárně na prohlížeče (ten Electron byl uveden v závorce, protože je postavený na stejné technologii).

Možná to používám moc intenzivně, možná mám moc otevřených stránek zároveň, ale... když se mi nečekaně roztočí ventilátor v počítači, tak se podívám na výpis procesů a prakticky vždy je na vině Firefox, případně (méně často) Thunderbird nebo Chromium.

U běhového prostředí určeného ke spouštění nedůvěryhodného kódu náhodně staženého z internetu bych čekal, že si s tím dokáže poradit a ty prasácky napsané webové aplikace zkrotí. Pro začátek bych čekal, že stránky, na které se uživatel zrovna nedívá, nebudou spotřebovávat žádný CPU, nějakou RAM ano (ale po čase je možné je odložit na disk a načíst až budou potřeba). Výjimkou může být to, když web chce kontrolovat, zda např. přišla nová zpráva – ale na to má mít omezený počet „cyklů“ v čase. Rozhodně se nemá dít to, že uživatel v prohlížeči nic nedělá, používá jiné aplikace, a najednou vyskočí vytížení CPU na 100 % nebo víc. Pokud uživatel záměrně chce nechat něco počítat na pozadí, tak to může explicitně povolit.

Ano, je možné, že Firefox je o něco horší než Chromium (proto od něj nejspíš taky odejdu), ale obecně dnes WWW prohlížeče patří mezi nejnáročnější aplikace.

Nicméně vrátil bych se k pointě komentáře: 1) bez www prohlížečů dneska nejde moc fungovat, je to nutné zlo, 2) www prohlížeče (a v nich běžící stránky / aplikace) jsou náročné na zdroje, 3) klasické pravidlo nám říká, že máme v první řadě optimalizovat místo, kde dochází k největším ztrátám. Je tedy hezké optimalizovat blikající kurzor v terminálu, ale z globálního hlediska to moc užitku nepřinese, protože ty největší ztráty jsou jinde. Je to podobná logika jako když mi někdo povídá o optimalizacích, kterými ušetří pár kilobajtů... a pak dá na web automaticky přehrávané video, které způsobí, že se nechtěně (než to uživatelé stihnou vypnout) stáhnou desítky nebo stovky megabajtů. Nemá cenu řešit halíře, když mi jinde utíkají desetitisíce.

(ten Electron byl uveden v závorce, protože je postavený na stejné technologii)

Ano, byl uveden rovnou dvakrát.

Ale vlastně díky. Stejně jako před mnoha lety, když jsem to nevydržel a člověku, který tvrdil, že kvůli javě je nutné mít 4GB RAM, tak jsem mu na 64MB virtuálce jasně ukázal, že ne, tak teď jsem si potvrdil, že electronové appky nejsou vůbec žravé. Jen bych byl fakt rád, kdyby se tyto různé pomluvy na odborných webech přestaly objevovat. Nebo alespoň s ověřitelným důkazem (typu běžte na tohle url a vidíte, prohlížeč si vzal xyzGB RAM).

Pro začátek bych čekal, že stránky, na které se uživatel zrovna nedívá...

Tohle ale funguje hezky dlouho. Chrome, Firefox i Edge po nějaké době "vypnou" taby, na které se dlouho nesáhlo. Ve FF je to už takových 10 let (ale tohle klidně může být vlastnost TreeStyleTab, kde se předpokládá, že těch tabů budou stovky).

Rozhodně se nemá dít to, že uživatel v prohlížeči nic nedělá, používá jiné aplikace, a najednou vyskočí vytížení CPU na 100 % nebo víc.

Proč by se to rozhodně nemělo dít? Já teda už o dob Windows NT (a to ani nemluvím o linuxu) naopak očekávám, že když už teda máme multiprocesing a už skoro 20 let i vícejádrové procesory do desktopů, tak skutečně očekávám, že poběží všechny procesy bez ohledu na to, na které appce mám zrovna focus. A jestli nějaký z pěti set tabů zrovna žere cpu, no tak ať a pokud mi to bude fakt hodně vadit, tak buď upravím pravidla v adblocku (za poslední roky možná tak jeden případ) nebo zareaguju jinak (třeba mu za trest snížím plánovací prioritu).

bez www prohlížečů dneska nejde moc fungovat, je to nutné zlo

Tuhle myšlenku jsem před lety zastával taky, ale buď jsem si zvykl, nebo prostě vlastně ani není jiná možnost. Loni jsem se tady v diskusi neúspěšně ptal na nějaký GUI jazyk, kde si napsat vlastní program, pro linux, windows. Jediná rozumná odpověď byla Java. Jasně, je to OK doporučení. No já jsem nakonec zvolil tu nejjednodušší metodu, napsal jsem to v golangu a html. Golang si běží na serveru, prohlížeč je všude, nemusím se rozčilovat nad tím, že IDE typu Lazarus ignoruje všechny standardy a instaluje se do C:/neco (prostě jako v tom roce 1997, chlapci si nějak nevšimli, že i MS si už dělá pořádek, takže to mají mít v Program Files), takže jsem spokojeně rezignoval a za víkend si to napsal na web. Takže už prohlížeče nepovažuji za zlo. Funguje to, žere to málo prostředků, ostatní multiOS gui prostředí vlastně kromě javy ani neexistují a jestli si mám vybrat, jestli do toho kterého os instaloval jdk nebo mono, nebo použít stávající libovolný prohlížeč, který tam stejně už je, tak hádej, co si vyberu.

www prohlížeče (a v nich běžící stránky / aplikace) jsou náročné na zdroje

Nejsou, ani když to zopakuješ stokrát.

Tak aspoň v názoru na Javu se shodneme.

Stručně ke žravosti Chromia:

$ free -h  # výchozí stav:
               total        used        free      shared  buff/cache   available
Mem:           125Gi        44Gi       9,9Gi       910Mi        70Gi        78Gi
Swap:             0B          0B          0B

$ free -h  # po spuštění prázdného Chromia:
               total        used        free      shared  buff/cache   available
Mem:           125Gi        44Gi       9,7Gi       925Mi        70Gi        78Gi
Swap:             0B          0B          0B

$ free -h  # po otevření jednoduché stránky typu Root.cz v Chromiu:
               total        used        free      shared  buff/cache   available
Mem:           125Gi        44Gi       9,5Gi       937Mi        70Gi        78Gi
Swap:             0B          0B          0B

Jinak uznávám, že je to podobná situace jako s tou Javou (až na to, že svět Javy je mi bližší oproti většině toho, co později vzniklo kolem webu).
Ale vadí mi, že spousta lidí žije pořád v iluzi, že webové aplikace jsou něco lehkého a nenáročného oproti nativním desktopovým nebo dokonce javovým aplikacím.

Ad „Tohle ale funguje hezky dlouho“

Funkce tam možná je, ale stejně je po čase lepší ten Firefox restartovat a lépe zavřít všechny otevřené panely (uložit si je do nějaké složky v oblíbených a zavřít). Po čase ten prohlížeč začne kolabovat a sekat se. Dá se to obejít tím, že člověk zavře jen to jedno okno a z jiného okna (prohlížeče pořád běží) vyvolat „Historie / Naposledy zavřená okna“ a zase si ty stránky obnovit. Ale je to otravné.

Je možné, že ten TreeStyleTab to řeší lépe.

Ad „naopak očekávám, že když už teda máme multiprocesing a už skoro 20 let i vícejádrové procesory do desktopů, tak skutečně očekávám, že poběží všechny procesy bez ohledu na to, na které appce mám zrovna focus“

U užitečných aplikací, které jsem si sám spustil, to očekávám taky. Ale tady se bavíme o webu, kde velkou část spotřeby zdrojů mají na svědomí reklamy a podobné hnusy. Tam by bylo rozumné to trpět jen stránkám, které si uživatel aktuálně prohlíží, a ne všem ostatním. U nich by stačil ten přiškrcený režim, ve kterém má webová aplikace jen pár cyklů na to, aby zkontrolovala např. nové zprávy. Pokud chce uživatel v nějakém panelu na pozadí těžit kryptoměny nebo něco podobně náročného, tak na to stačí jedno zaškrtávátko, kterým tenhle svůj zájem explicitně vyjádří. Za rozumný výchozí stav ale považuji, že ty aktuálně neprohlížené stránky jsou utlumené. Nebo myslíš, že je užitečné pálit výkon na kreslení nějakých přitroublých animací nebo na přehrávání videa, které uživatel nevidí ani neslyší?

Ad „Nejsou, ani když to zopakuješ stokrát.“

Stovky megabajtů na to, abych si jen přečetl článek, mi přijde hodně. A webové aplikace (nikoli stránky) žerou ještě násobně více. Můžeme se dohadovat, jestli je to „hodně“ nebo „málo“… jasně, od dob SNESů a třiosmšestek jsme se posunuli jinam a význam slov jako „hodně žravá aplikace“ jsou taky někde jinde. Navíc jako vývojář mám typicky dost výkonný počítač na danou dobu. Ale i tak mne to štve – mám tu několik větších programů v Javě, několik virtuálek (KVM/QEMU) a přesto, když mne nějaká aplikace obtěžuje svou nenažraností, tak je to typicky nějaká ta webová věc. Kromě toho znám dost běžných uživatelů, kteří upgradovali počítač a motivem pro ně nebylo to, že by hráli hry nebo vyvíjeli software nebo pouštěli několik dalších OS ve VM, ale to, že se jim ten starý počítač zadýchával při prostém prohlížení webu. To, co bývalo nenáročné a neškodné, je dnes často důvodem, proč si lidi musí koupit nový počítač.

Vadí mi ten přístup „ode zdi ke zdi“. Na jedné straně tu máme molochovité aplikace, které ti požerou většinu zdrojů, roztočí ventilátory, vyplácají baterku, ohoblují disk ze všech stran… a na druhé straně se lidi uchylují k opačnému extrému, vymýšlejí kraviny typu Gemini (jakási reinkarnace Gopheru) nebo se snaží nacpat do textového terminálu kde co – i programy, kde je vizuální reprezentace důležitá a GUI má pro ně perfektní smysl. Část lidí to táhne funkčně pod úroveň třicet let starých her a jiná část zase pomáhá zvyšovat tržby z prodejů RAM a CPU. Trochu mi tu chybí nějaká zlatá střední cesta…

Přitom i ten web býval docela fajn. Dodnes si pamatuji, jak jsem se před kolegou v mojí první pořádné práci zmínil, že mám web celkem rád, a on se mi vysmál – já si totiž tehdy tvořil jednoduché stránky pro sebe nebo maximálně nějakou malou zakázku, zatímco on se tím dřív živil v nějakém webovém studiu. Přitom ty jednoduché weby jde dělat i dnes, není nutné vylévat vaničku i s dítětem a tu technologii zavrhnout úplně. Ale většina webů tak dnes prostě nevypadá.

Mimochodem, když si pustím ve virtuálce Windows 2000 (totéž může mít člověk v OS/2) a v nich otevřu nebo vytvořím stránku s Java Appletem nebo ve Flashi, tak to běhá lépe než mnohé dnešní weby. A to navzdory režii virtualizace a obstarožního OS. A už tam měl člověk k dispozici vysokoúrovňový programovací jazyk a multimédia. Tehdy se to ale považovalo za vrchol nenažranosti.

A znovu připomínám: cílem nebylo rozpoutat flame war ale poukázat na to, že člověk má na počítači pravděpodobně jiná místa, která zasluhují optimalizaci, než je emulátor terminálu (a jeho blikající kurzor).

A znovu připomínám: cílem nebylo rozpoutat flame war ale poukázat na to, že člověk má na počítači pravděpodobně jiná místa, která zasluhují optimalizaci, než je emulátor terminálu (a jeho blikající kurzor).

Tohle je spíše věcí správné metriky a jejího vyhodnocení.

Pokud někdo optimalizoval terminál a místo latence 100ms získal 15ms, tak za mě je to mnohem lepší výsledek, než na stroji se 128GB RAM řešit to, že nový tab (resp. spíš první*) v prohlížeči žere 200MB.

Já vlastně moc nevím co vlastně řešíš. Jen pro kontext, 128GB paměti v Alze stojí 5600Kč. Není to nijak enormně moc paměti, není to žádný extrém pro vývojáře, je to naprosto lidové za lidovou cenu. Já se v praxi spíš setkávám s tím, že někdo optimalizoval tak moc, že je to dneska, po pár letech, velký problém. Můj přístup "používejte BIGINT prostě jako default typ na vše" zatím v praxi nikdy nenarazil a kromě pár uštěpačných poznámek typu "to opravdu v receptu bude 2^64 ingrediencí?" to ve skutečnosti vlastně jenom "just works". Ale až moc často se setkávám s tím, že někdo řekl "16b stačí" a už se používá třetí reserved slot v nějakém datovém kontejneru (a ještě že tam jsou). Takže v době, kdy lze z kapesného koupit 32, 64, 128GB RAM mi ta diskuse vlastně přijde dost nepodstatná a z mého pohledu je mnohem užitečnější a do budoucnosti mnohem méně problémová rada "používejte klidně největší datové typy, které v jazyku najdete" než "optimalizujte 100MB appku".

*) Když těch tabů s root.cz otevřeš tisíc, tak to nebude žrát 1000*200MB, že? ;-) To jenom taková poznámka ke způsobu měření.

Ještě k tomu terminálu, ono to takhle v diskusi vypadá úsměvně, ale jak na linuxu tak na widlích je to ve skutečnosti reálný problém (pro mě jako pro admina). Na linuxu jsem zkoušel asi 4 a už nevím, u čeho jsem ve i3wm skončil, na to si možná vzpomenu, ale rozhodně to nebyl ten default. Na widlích jsem dospěl k nepoužitelnosti putty, potom mi někdo poradil terminál v cygwinu (tak ten je extrémně pomalý a lagující) a nakonec to vyřešil MS se svým Windows Terminal. Takže jestli někdo přepsal terminál na Vulkan a konečně to v roce 2025 není problém, tak díky za to.

A z hlediska uživatelské řešitelnosti, tak zatímco v případě "nenažranosti prohlížečů" (která neexistuje) to lze snadno vyřešit nákupem větší RAM, tak v případě lagujícího terminálu ti vlastně nepomůže vůbec nic. Protože já jsem to před těmi 10 lety řešil na herním desktopu, takže z HW hlediska vlastně nebylo kam jít.

Ja treba na tu pomalost narazil. Take jsem od jiste doby delal ve VS Code vsechno, ale treba dlouhy text (v mem pripade dizertacka) se me v tom sekal a psani tam melo vysokou odezvu. Takze pro to psani zpatky do vimu. Pri psani kodu ale pomalost nepozoruji, tam jsem spokojeny uzivatel.