Aber mein Anlaufpunkt war eher der, dass Java ja mit Bytecode übersetztwird, der nicht so Prozessornah arbeitet.
Damit wird die Leistung halt in Mitleidenschaft gezogen, was sich aber denk ich mal erst bemerkbar macht, wenn man einen langsamen PC hat.
Genau das ist die Vorstellung, die viele Programmierer haben, aber so nicht zutrifft. Die Java VM ist ein sogenannter JIT (Just in Time) Compiler. Der Bytecode wird dabei erst beim Starten des Programms in Maschinencode umgewandelt, um so noch spezifisch für das Zielsystem optimieren zu können. Das kostet natürlich Zeit, weswegen Java Programme meist etwas länger benötigen um zu starten. Bei einem Programm/Spiel das länger läuft sind die paar Sekunden aber eher vernachlässigbar. Wenn nicht, gibt es auch Java Compiler, die die Möglichkeit haben den Bytecode vorher schon in Maschinencode zu wandeln. Damit verliert man aber natürlich auch die Optimierungsmöglichkeit.
Was auch viele nicht wissen ist, dass Visual C++ und viele andere Compiler als ersten Schritt ebenfalls Bytecode erstellen. Das Problem ist einfach, dass Maschinencode zu wenig Informationen enthält um ordentlich optimiert zu werden. Daher werden die einzelnen Quellcode Dateien erst einmal in einen Bytecode compiliert, damit der Linker beim Zusammensetzen der einzelnen Objektfiles noch optimieren kann. Bei Visual C++ übernimmt der Linker auch gleich das Umwandeln in Maschinencode, aber auch das ist bei C++ optional. CLang ist z.B. ein C++ Compiler der Bytecode für die LLVM erstellt.
Die Probleme die Java hat liegen z.B. in der Speicherverwaltung. Der Garbage Collector und die automatische Erkennung ob Variablen nur lokal genutzt werden oder nicht, erzeugen schon deutlichen Overhead. Und auch an anderen Stellen wurde nicht so stark wie bei C++ darauf geachtet, das kein Overhead entsteht.