[108] Myslím, že v otázce bytecódu se mýlíte.
Velké množství dnešních kompilátorů pracuje interně s určitým bytekódem, který nemá přímou vazbu na výsledný strojový kód. První fáze kompilace (front end) vytvoří interní bytekód ze zdrojového kódu, druhá část (back end) generuje z bytekódu strojový kód zvolené platformy.
Java pouze při "kompilaci" před distribucí vynechává druhou fázi a provádí ji až za běhu dynamicky.
A protože dynamická kompilace může optimalizovat kód na konkrétní procesor (statická kompilace se většinou omezuje na skupinu procesorů; pro šťouraly zdůrazňuji slovo většinou :-) ), je výsledek velmi rychlý; přesněji řečeno, má potenciál být velmi rychlý.
Samozřejmě ovšem dramaticky záleží na tom, kolik kódu je potřeba kompilovat a kolikrát se daný kód prochází. U algoritmů, které jsou na zkompilování krátké, ale procesor je prochází mnohonásobně může být výsledek teoreticky rychlejší než v C...
Aplikace psané v Javě nejsou pomalé z důvodu, že by bytekód byl špatně zvolený... Příčiny jsou podle mě jinde a jsou (jak to vidím já) zhruba 3:
- Java musí provádět spoustu kontrol, které si programátor může dovolit v C vynechat, když ví co dělá
- lidé, co píšou v Javě jsou většinou hodně vzdálení HW.... většinou nemají tušení jak procesory fungují, jak efektivně pracovat s pamětí a cache...
- protože to je jazyk "in" a ne příliš komplikovaný, spoustu Javovských aplikací dělají zmínění lepiči :-)
ČLÁNKY DO MAILU