Jein. Der Geschwindigkeitsvorteil von (gut) compiliertem Code zu Interpreter ist beachtlich. Du musst bedenken, der Interpreter durchläuft beim Ausführen den Syntaxbaum, hat also einiges an Verwaltungsaufwand und selbst bei der Ausführung eines einzelnen Knoten kommen zusätzliche Befehle hinzu.Zitat
Wo der Compiler also vielleicht 3-5 Maschinenanweisungen für einen Knoten produziert, laufen beim Interpreter ungleich mehr Anweisungen für denselben Knoten ab. Hinzu kommt, dass für bestimmte Anwendungen eventuell spezielle Maschinenanweisungen bereit stehen, die das ganze noch effizienter und schneller ausführen, der Compiler kann gezielt solche Anweisungen statt "normaler" Anweisungen nutzen, beim Interpreter ist das nicht unbedingt möglich.
Der Compiler vollführt beim Compilieren eine Unmenge an Analyse- und Optimierungsaufwand der sich in einer langsamen Ausführung äussern. Wenn du mal ein größeres Projekt selbst compiliert hast (zB Open Office) weißt du was das heißt. Dieser Aufwand muss aber nur 1 mal gemacht werden, nämlich beim Entwickler der seinen Code compiliert - der ausführbare Code läuft deswegen aber sehr flott.
Wenn der Interpreter diese ganzen Analysen auch machen würde, sobald er ein Programm einliest, könnte er vielleicht die Ausführung des Codes beschleunigen, würde aber mitunter minutenlang rechnen, bevor er mit der Auführung beginnt - was in der Praxis natürlich undenkbar ist.
Der Interpreter hat dabei noch das Problem, das das Interpreterprogramm anwesend sein muss wenn man das Programm ausführen muss, ebenso wie der zu interpretierende Code - beim compilierten Programm braucht man nur das Programm, das man ausführen will.
Ein weiterer Vorteil des Compilers ist das compilieren in andere Zielformate. Du kannst aus demselben Code, sofern der Compiler es unterstützt, ausführbare Programme für ganz unterschiedliche Plattformen produzieren, von anderen Betriebssystemen bis hin zu gänzlich anderer Hardware. Beim Interpreter müsstest du den kompletten Interpreter für die Zielplattform portieren - ein ziemlicher Aufwand.
Java versucht aber genau so etwas, eine Art Verbindung von beidem. Java-Code wird in ein Zwischenformat compiliert, den sogenannten Bytecode. Dieses "Java-Programm" wird dann beim Benutzer durch die Java Virtual Machine (JVM) zur Laufzeit interpretiert. Der Vorteil des Entwickler ist, das sein Code in ein portables Format umgewandelt wird, er also die Besonderheiten der Zielplattform nicht beachten muss - compile once, run everywhere.
Nachteil ist, dass der Benutzer dafür sorgen muss, das er eine passende JVM installiert hat, die natürlich auch jede Menge Ressourcen schluckt und Java-Code ist trotz aller Optimierungen immer noch deutlich langsamer als nativ compilierter C(++) Code. Gerade aktuelle Top-Spiele brauchen aber Geschwindigkeit, Java fällt dort alleine deswegen schon durch.
Der Geschwindigkeitsvorteil mag sich nur "graduell" unterscheiden, ist aber in der Praxis bei einigen Anwendungen gravierend. Ein Spaziergang unterscheidet sich ja auch nur "graduell" von einem olympischen 100-Meter Sprint - eigentlich wird bei beiden ja dasselbe gemacht, oder?![]()