Vlákno názorů k článku Velikost objektů v Javě od alias - skoda ze se clanek nevenuje vysvetleni realne spotreby...

Může být, vypnutím JIT se zníží paměťová náročnost Javy někdy celkem podstatně.

NetBeans nejsou editor, ale IDE. Nevím, jak v případě C/C++, ale v případě Javy drží v paměti informace o projektu a všech třídách a vazbách, aby programátorovy usnadnily práci (to je účel IDE, kdyby ty nápovědy a pomůcky nechtěl, použije jen editor). To, že IDE potřebuje hodně paměti, vychází z toho, jaké služby má poskytovat – a ve spotřebě paměti na desktopu má IDE konkurenci podle mne jen ve zpracování videa a velkých obrázků.

A zvládne Geany něco jako http://blog.v6ak.com/2013/01/grahamuv-problem-v-jave-je-ukecany-vadi.html ? (Toto je jen stručný náznak, co takové IDE umí.)

Jinak přejmenování metody není triviální operace, musí se hledat všechna použití.

jedna obyc hra (minecraft, holy zaklad bez pluginu, novy svet) sezrat dohromady gigabyte pameti

defaultne ma MC nastaveno 1GB ;). ale zrovna u her neni >512MB nic neobvykleho, navic u MC pokud pouzivate view distance na far - tech nactenych chunku je celkem hodne (myslim, ze se i cachuji).

DDO client (Dungeons and Dragons Online), nativní aplikace (tedy ne JAVA), průměrná zabíratelnost paměti přes 1.1GB. Když se mu zapne cachování grafiky, zabere o dalších 400MB víc.

To budou Netbeans bud spatne napsane, protoze Eclipse (+- srovnatelne co se tyce featur) me jede bez problemu na komplu s 256 MB RAM (Java + C vyvoj).

Minecraft, tam asi zalezi, jak je reprezentovan herni svet, precejen voxely jsou z hlediska spotreby pameti vlastne ta nejnarocnejsi struktura pro 3d modely :)

Je to pravda asi ponekud netypicka konfigurace Fluxbox + Eclipse + spousta ruznych JDK (OpenJDK, Oracle JDK, IBM, JamVM).

Tvorba kodu (refaktoring), ladeni, vsechny ostatni pluginy jsou samozrejme zakazane.

jo to je pravda. Dokonce bych rekl z pozorovani Eclipse, ze pametova narocnost neroste s projektem linearne, ale snad od jiste chvile exponencialne :P

To by snad měla java compilátor být schopen přepsat na používání string-builderu ne?

Kompilátor to přepisuje. Ale když ten původní kód napíšete špatně, pro každé sečtení se vytvoří nový StringBuilder, řetězce se spojí, zkonvertují na String a vrátí, a takhle se to opakuje několikrát za sebou. Když to přepíšete, dá se to udělat s jedním StringBuilderem a spojit vše najednou.

V první řadě bych chtěl říct, že moje vlastní zkušenosti jsou velice podobné; programy psané v Javě jsou výrazně pomalejší a náročnější na paměť, než jiné (třeba C/C++) varianty, co toho uměly zhruba stejně tolik. Proto jsem v dobách kdy jsem byl úplný BFU (teď už jen tak trochu BFU :3) se naučil Java programy ignorovat a nepoužívat. Čas od času se mi samozřejmě stalo, že jsem si nevšiml, že je to v Javě, ale brzy to bylo "sakra, ten program je tak náročný a pomalý... vždyť toho tolik nepotřebuje... hele, není to v Javě? *klik* *klik* ... no jasně, je. Uninstall"...

Na druhou stranu ale musím souhlasit s názory, že Vaše příklady jsou poněkud nešťastné. Netbeans jsou IDE, tedy obsahují velké množství funkcí jako pomůcky při programování. Kupříkladu já na PC používám QtCreator (psaný v C++), který umí refactoring (fakt perfektní, nic lepšího jsem neviděl - i když uznávám, že ve chvíli, kdy vytáhnu šablony a především složité šablonové struktury, už leccos přehlédne) a detekuje chyby v kódu a ve chvíli, kdy otevřu trošičku větší projekt (1 - 2MB zdrojového kódu), sežere okolo 150MB RAM. Samozřejmě, když jsem používal DevC++, nároky byly někde jinde, jenže to i funkce, které to umělo.

Příklad s Minecraftem je taktéž lehce nešťastný. Ten ukládá každou krychli, i když je to jen vzduch, do paměti a nemusí se to zdát, ale těch kostek je tam opravdu hodně. Nedávno jsem si taky dělal takový jednoduchý voxelový engine a ty paměťové nároky jsou docela srovnatelné. Sám Notch, původní autor Minecraftu, přiznává, že hra není optimalizovaná (spíš naopak).

Takže v případě těchto programů jsou větší nároky na paměť pochopitelné a řekl bych, že nevyhnutelné. Ale samozřejmě nepopírám, že kdyby byly dělány v např. C/C++, ušetřilo by se velké množství výkonu.

Příklad s Minecraftem je taktéž lehce nešťastný. Ten ukládá každou krychli, i když je to jen vzduch, do paměti a nemusí se to zdát, ale těch kostek je tam opravdu hodně. Nedávno jsem si taky dělal takový jednoduchý voxelový engine a ty paměťové nároky jsou docela srovnatelné. Sám Notch, původní autor Minecraftu, přiznává, že hra není optimalizovaná (spíš naopak).

MC nepoužívá octree, tj. každá elementární kostička má svoji sólo reprezentaci? :o To je dosti drsné. :)

No, tak teď doufám, že jsem neplácl nějakou blbost *kapka* nicméně takové jsou moje informace, byť mohou být zastaralé (přinejmenším soudě dle mého rychlého Googlení). Nicméně nebyl by octree docela nepříjemným zpomalením pro random access, který může být používán nejen pro pokládání a odstraňování objektů, ale i detekci kolizí?

Neřekl bych. Obecně jde o nárůst operační složitosti z lineární (přímý přístup do [obrovského] pole) na logaritmickou (průchod stromem), což za rapidní pokles nároků na paměť obvykle stojí. Průchod octree bude pomalejší než přímý přístup k prvku pole; na druhou stranu naopak nebude nutné zkoumat množství jednotlivých elementů, když se třeba výpočet kolize dvou objektů odehraje ve vysoké úrovni stromu (tahle agregace pomůže i k ořezávání neviditelných částí scény při renderingu apod.).

Samozřejmě je vždy třeba zvážit všechny okolnosti konkrétní situace. Zde tedy např. rozměry světa, stupeň jeho rozmanitosti (tj. zda se vyplatí čistý octree, nebo nějaká hybridní struktura), frekvence a rozsah změn uspořádání světa (naprostá většina hmoty je po většinu času statická) apod.

Myslím si tedy, že nějaká adaptivní struktura by tomuto enginu v součtu prospěla, pokud ji nemá.

No, já už situaci moc nesledoval, ale taktéž jsem porůznu četl a slyšel, že se Java poslední dobou výrazně optimalizuje.

U mě to zabily prakticky všechny aplikace, co jsem zkoušel (od stahovačů, přes hry až po editory a IDE). Poslední dobou jsem používal pouze program Esmska, protože jsem nenašel C/C++/... alternativu a vzhledem k řídkému využití prostě akceptuji, že reaguje pomaleji.

Původní StarOffice (ten jsem nikdy neměl) byl původně v C++, ale Sun poté, co to koupil, do toho nacpal Javu, aby svět přesvědčil o její důležitosti. Pamatuju si PC s Celeronem 1,1 GHz a 192 MB RAM, bylo to kolem roku 2003. OpenOffice se na tom pouštěl víc než půl minuty (první start). Nevím, jestli to bylo Javou, nebo špatnými programátory, ale chápu, že to někoho mohlo odradit. Zejména z pohledu pamětníka AmiPro 3.0, který bylo rychlejší i na stroji s 10x pomalejším taktem CPU.

> Jenže tohle je obvyklé klišé: Když je pomalý program v javě, může za to java, když je pomalý program v čemkoliv jiném, může za to programátor.

S tímhle se setkávám celkem často, proto se snažím dávat si na to pozor. Proto nepopírám, že za pomalé programy v Javě nemohou jejich autoři, problém je ale v tom, že drtivá většina programů v Javě, se kterými jsem se setkal byla výrazně pomalejší a v žádném jiném jazyce jsem se s tím nesetkal.