Pridam par postrehu k optimalizaci zalozenych na vlastnich zkusenostech; i zde plati to o predcasne optimalizaci:
1. byl jsem prijemne prekvapen, kdyz jsem zjistil, ze kresleni do Graphics2D (treba toho z JPanel) je akcelerovane (testovano na Win7), na dratenych modelech jsem dosahoval stovky fps, jine sceny jsem nezkousel. Samozrejme to je jen pro 2D, projekci si programator musi resit sam...
2. autori jvm se chvastali rychlym GC, tak jsem to zkousel na jednoduchem programu - alokoval objekty a daval je do pole, pak se na tom neco pocitalo a tak porad dokola. V jave mi vysla propustnost kolem 3GB/s, v MSVC C++ 300MB, cili 10x rychlejsi v jave. Z toho plyne, ze recyklace objektu se nemusi resit zdaleka tak casto jako v c++, navic to ani neni doporucovano. Nejlepe se jvm vyporada s kratce zijicimi objekty.
Ostatne i to zobrazeni casu GC ukazuje, ze zaseky jsou v radu ms...
Mate pravdu, pokud se vytvari kratce zijici objekty, je spravce pameti v JVM velmi rychly - proste jen pri alokaci posune (vnitrni) ukazatel a to je vse, protoze ma lokalni buffer pro kazde vlakno a vi, ze cast heapu pred tim ukazatelem je volna. Navic alokace se provede bez zamykani, takze taky +, pokud toho aplikace dokaze vyuzit.
Problem samozrejme nastava ve chvili, kdy se vytvari objekty ve vnitrnich programovych smyckach, coz si sice programatori hlidaji (doufam :-), ale nekdy to neni patrne, treba zrovna Swing si porad neco dela pod poklickou, takze pro hry to neni to prave ...
Priznam se, ze si casto objekty alokuji primo zhuverile, proste nad tim vubec nepremyslim a zatim jsem nenarazil na to, ze by zrovna alokace a GC byly uzkym hrdlem. Par procent behu si to vezme, ale za tu usporu mi zesloziteni aplikace nestoji.
Co se tyce swingu, mam jednu aplikaci, kde se vkladaji radove stovky ruznych prvku na panel a obecne to zadne problemy nedela, cpu to nezere. Ovsem stava se, ze tam zacne behat nekonecny refresh, bohuzel vetsinou az po nekolika dnech behu, takze se to blbe chyta pod debuggerem.
Nechtelo by se vam porovnat dobu behu pri kresleni na swingovy JPanel a do okna pres SDL? Pripadne i na ruznych systemech? Mohlo by to byt zajimave.
diky
Ono u her a GUI programu vadi spis zastavovani threadu aplikace, nez rekneme snizena vykonnost celeho programu. Proto taky dost lidi povazuje Javu za nevhodnou pro GUI, ne ze by ty aplikace byly celkove pomale, ale ze se nekdy "zamysli" a to uzivatel citi (u her jeste hur).
Vetsinou se to da vyresit prave obejitim Swingu, jehoz "lightweight" komponenty jsou tezkotonaznejsi nez nativni widgety :D a minimalizaci prace GC, popr. nastavenim heapu tak, aby se idealne spoustel GC jen nad young gen.
Porovnani Swingu (JPanel)) versus SDL muzu vyzkouset, dobry napad!
Demonstracny priklad v C sa aspon mne neskompiluje - ludom s podobnym problemom odporucam zlinkovat to aj s math kniznicou. V Makefile teda staci LFLAGS napisat ako:
LFLAGS=-lSDLmain -lSDL -lm
prip. kompilovat cez
gcc -ansi -Wall -pedantic -O9 -ffast-math sdl_test.c -lSDLmain -lSDL -lm
Diky za upozorneni, na nekterych systemech se to skutecne nepodari zkompilovat bez libm.
Oprava je zde:
http://icedtea.classpath.org/people/ptisnovs/jvm-tools/rev/79a9aef00fbc