Vlákno názorů k článku Řešení vysokých cen RAM a SSD hned tak nebude, přepněme na skromnost od halali - Skvělej článek, díky! Přidám svůj příklad z praxe :-) U...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 3. 2026 9:41

    halali

    Skvělej článek, díky!

    Přidám svůj příklad z praxe :-)

    U klienta běží jedna interní REST služba. Psaná v Java 11, na Spring Boot s Hibernate a takovou tou další Java klasikou knihoven (výsledný JAR má asi 250MB). Běžně si za běhu bere kolem 1,5GB RAM. Není to nic kritického, takže stačí jedna běžící instance. Když náhodou spadne, tak se nic vážného nestane a prostě se znovu rozjede. Není žádná motivace, ani vůle, s ní něco dalšího dělat, protože se to prostě klientovi finančně nevyplatí. Evidentně psaná s vědomím, že svému účelu to poslouží a paměti i procesor stojí pár kaček, tak proč si lámat hlavu přemýšlením nad věcmi jako co to je a jak funguje garbage collector, co vůbec znamená slovo optimalizace a tak dále...

    Já se zrovna učil Rust a tahle služba mi přišla jako vhodný praktický příklad, na kterém bych se ho mohl učit.
    Tak jsem jí ve svém volné čase přepsal do Rustu (ručně, žádný AI). Měl jsem totiž motivaci a chtěl se to naučit a vyzkoušet si čerstvě nabyté znalosti Rustu v praxi a ještě k tomu jsem se naučil Axum, Tokio, Serde, sqlx. Nakonec se ukázalo, že té službě stačí za běhu pouze 50MG RAM a na disku ta jedna binárka zabere cca 15MB a ještě má mnohem lepší odezvu. A když by náhodou spadla, tak start je tak rychlej, že si toho pádu ani nikdo nevšimne.

    Dobře, u téhle konkrétní služby se nějaký přepis třeba zrovna moc nevyplatí a výsledkem je pouze má obrovská radost, že to takhle parádně a levně šlape :-) Ale když si představím ty mraky ostatních služeb, po různých cloudech, firemních serverech, atd., které žerou stejně nebo i ještě víc a k tomu běží třeba ve 4 instancích mezi které rozhazuje dotazy load balancer, to už by byla slušná úspora zdrojů :-)

    Nějaké možnosti ušetřit tedy stále pořád máme ;-) Jenom k tomu musí být ta správná motivace :-)

    A třeba se s těma rostoucíma cenama pamětí zase vrátí doba, kdy 640kb RAM bude muset stačit každému :-D

  • 6. 3. 2026 15:21

    Vít Šesták

    Pokud by nebylo cílem se naučit něco v Rustu, možná by lepší cost/benefit ratio mělo native-image z GraalVM. Ale záleží, jak na to je připravený kód (a zejména knihovny), dává to z principu určitá omezení, například je omezená (byť ne nemožná – záleží na konfiguraci) reflexe.

  • 7. 3. 2026 8:53

    Přezdívka

    Zrovna včera jsem viděn na redditu:

    https://www.reddit.com/r/java/comments/1rmaqdt/wen_built_a_tiny_discord_bot_in_java_25_zgc_on_a/

    Ano, Java je náročná na paměť. Ale dá se s tím něco dělat.

    Jinak, možná to není tak cool, jako Rust, ale node.js se stává použitelným pro spoustu věcí...

  • 8. 3. 2026 4:42

    Ladis

    Zajímavá úvaha k rychlosti: RAMKy sice máme habaděj (teda dokud neodezní krize), ale její rychlost je omezená. Tzn. aby původní verze beroucí 1,5 GB RAM byla stejně rychlá jako nová s 50 MB RAM, tak by musela být RAM rychlejší 30x. (Pokud hardware RAMky umí číst některé části paralelně a ta menší aplikace nemá data rozprostřeně, tak je ten koeficient menší.)

    8. 3. 2026, 04:44 editováno autorem komentáře

  • 8. 3. 2026 12:07

    Jan Judas

    On to asi nebyl skript, co rychle schroupe 1.5 GB dat a pak skončí. Byla to nejspíš nějaká dlouho běžící aplikace, kde většina věcí v paměti prostě "leží" (a můžou být reálně klidně odswapované na disk). A Java je paměťově prostě mnohem nenažranější, všechno je pointer, takže 10x zmenšení v Rustu by mě ani nepřekvapovalo. 30x už je ale docela dost.