Problém jazyků je ten, že se k ní vyjadřují blbci, kteří v tom napsali Hello World. Rychlost běhu C#/Java je naprosto srovnatelná. Oboje se kompiluje do nativního kódu, u Javy můžete dokonce nastavit kompilaci při prvním průběhu programu. Říká se tomu Virtual Machine Hints, to jen na opravu místních kecalů. Častý mýtus mnoha lidí je, že prostý překlad do jiného jazyka, který se následně kompiluje do strojového kódu, cokoliv urychlí. Takové pověře může uvěřit jen ten, který zatím vůbec netuší, co se děje s jeho kódem. C# i Java mohou být stejně rychlé, někdy dokonce i rychlejší než jazyky, kterým se říká "nativní", jako je C. Proč ? Inu:
1) VM má k dispozici informace o vašem hardware a kompiluje přímo pro něj, nikoliv univerzálně. Některé operace (hlavně aritmetika a práce se soubory) se tak dají značně urychlit.
2) Důvod, proč kód v jazycích, které dovolují práci na nižší úrovni abstrakce, bývá po překladu rychlejší, je jednoduchý: Malá obecnost řešení a málo bordelu. Otázka bývá špatně položena. Vůbec nejde o to, jestli něco generuje nativní instrukce a něco nikoliv (oboje lze přinutit ke kompletnímu překladu). Jde o to, jak generovaný kód vypadá. Funkce, které voláte v Javě či C#, jsou přeci jen univerzálnější. Nemusíte sledovat pointery na soubory. Java dokonce od verze 7 automaticky uzavírá alokované zdroje v kontrolovaných blocích. A protože jsou napsané univerzálně, jejich strojový kód vypadá jinak než ten, který vygeneruje Vámi napsaný prográmek v C/C++, který ale nevyhovuje tak obecnému použití. Pokud použijete v C++ obecnou knihovnu, vůbec nemusí být rychlejší než přeložený program v Javě, někdy naopak.
V Javě můžete kritické části implementovat v jiném jazyce, říká se tomu JNI. A na zbytek použít Java knihovny. Říká se, tj. nemám to ověření, že volání nativní metody trvá okolo 35 nanosekund. Pokud je její průběh rozumně dlouhý (což u kritických částí programu bude), máte k dispozici zbraň slušného kalibru. Krásná ukázka, že Java umí běžet naprosto stejně rychle jako program v C++, je JOGL. Když na procesoru počítáte matice a pouze výsledný předáváte shaderům, pak zjistíte že Java umí optimalizovat práci s maticí reprezentovanou jednorozměrným polem naprosto skvěle - tj. práce s ní je stejný fofr jako když to samé izoluji a napíši v C. S tím že C kód má o dost horší metriku.
Výhody a nevýhody obojího si musí každý zvážit sám.
Závěr je následující: Jestliže někdo hledá náhradu za C#, pak v něm pravděpodobně nic moc neumí či nic seriózního nedělá. C# se totiž nahradit nedá, pomineme-li ostatní jazyky z balíku .NET. Má jinou úlohu než Java, jeho API je jiné (jestli někdo přijde s tím, že oboje má kolekce a podobné kecy...). Dokonce i vláknování, což většina programátorů nedělá a neumí, je v C# připravené pro Windows. Proto je jeho portování (jako projekt Mono) tak šíleně kontraproduktivní. Dotnet je spjatý s platformou Windows, na které dejme tomu funguje dobře a rozumí si s ní. Čím toto chcete nahradit ? Zkuste v Javě najít rozlišení vláke na foreground/brackground. Zkuste v ní najít podporu D3D. To vše je Windows only.
Všechny tyto thready jsou jen důkazem toho, jak je teorie a vzdělání důležité.