Es gibt viele Gründe, die für die Wahl einer Sprache X gegenüber einer Sprache Y in Betracht gezogen werden können. Programmlesbarkeit, einfache Programmierung, Portabilität auf viele Plattformen und das Vorhandensein guter Programmierumgebungen können solche Gründe sein. Ich werde jedoch nur die in der Anfrage geforderte Ausführungsgeschwindigkeit berücksichtigen. Die Frage scheint zum Beispiel die Geschwindigkeit der Entwicklung nicht zu berücksichtigen.
Zwei Sprachen können zu demselben Bytecode kompiliert werden, dies bedeutet jedoch nicht, dass derselbe Code erzeugt wird.
Eigentlich ist Bytecode nur Code für eine bestimmte virtuelle Maschine. Es hat technische Vorteile, führt jedoch keine grundlegenden Unterschiede zum direkten Kompilieren für eine bestimmte Hardware ein. Sie können also auch zwei Sprachen vergleichen, die für die direkte Ausführung auf demselben Computer kompiliert wurden.
Das Problem der relativen Geschwindigkeit von Sprachen ist jedoch alt und geht auf die ersten Compiler zurück.
In jenen frühen Zeiten war der Fachmann jahrelang der Ansicht, dass handgeschriebener Code schneller war als kompilierter Code. Mit anderen Worten, die Maschinensprache galt als schneller als Hochsprachen wie Cobol oder Fortran. Und es war sowohl schneller als auch normalerweise kleiner. Hochrangige Sprachen entwickelten sich immer noch, weil sie für viele Menschen, die keine Informatiker waren, viel einfacher zu benutzen waren. Die Kosten für die Verwendung von Hochsprachen hatten sogar einen Namen: das Erweiterungsverhältnis, das die Größe des generierten Codes (ein sehr wichtiges Problem in diesen Zeiten) oder die Anzahl der tatsächlich ausgeführten Anweisungen betreffen könnte. Das Konzept war hauptsächlich experimentell, aber das Verhältnis war anfangs größer als 1, da die Compiler nach heutigen Maßstäben eine relativ einfache Aufgabe erledigten.
So war die Maschinensprache schneller als etwa Fortran.
Das änderte sich natürlich im Laufe der Jahre, als die Compiler immer ausgefeilter wurden und das Programmieren in Assemblersprache heutzutage sehr selten ist. In den meisten Anwendungen können Assembler-Programme nur schlecht mit Code mithalten, der durch die Optimierung von Compilern generiert wurde.
Dies zeigt, dass ein Hauptproblem die Qualität der für die jeweilige Sprache verfügbaren Compiler, ihre Fähigkeit, den Quellcode zu analysieren und entsprechend zu optimieren, ist.
Diese Fähigkeit kann in gewissem Umfang von den Merkmalen der Sprache abhängen, um die strukturellen und mathematischen Eigenschaften der Quelle hervorzuheben und dem Compiler die Arbeit zu erleichtern. Beispielsweise könnte eine Sprache die Aufnahme von Aussagen über die algebraischen Eigenschaften von benutzerdefinierten Funktionen ermöglichen, damit der Compiler diese Eigenschaften für Optimierungszwecke verwenden kann.
Der Kompilierungsprozess kann einfacher sein, wodurch ein besserer Code erzeugt wird, wenn das Programmierparadigma der Sprache näher an den Merkmalen der Maschinen liegt, die den Code interpretieren, egal ob es sich um eine reale oder eine virtuelle Maschine handelt.
Ein weiterer Punkt ist, ob die in der Sprache implementierten Paradigmen auf die Art des zu programmierenden Problems beschränkt sind. Es ist zu erwarten, dass eine Programmiersprache, die auf bestimmte Programmierparadigmen spezialisiert ist, Merkmale, die mit diesem Paradigma zusammenhängen, sehr effizient kompiliert. Daher kann die Wahl einer Programmiersprache aus Gründen der Klarheit und Geschwindigkeit von der Wahl einer Programmiersprache abhängen, die an die Art des zu programmierenden Problems angepaßt ist.
Die Popularität von C für die Systemprogrammierung ist wahrscheinlich darauf zurückzuführen, dass C der Maschinenarchitektur nahe kommt und dass die Systemprogrammierung auch direkt mit dieser Architektur zusammenhängt.
Einige andere Probleme lassen sich einfacher programmieren, da sie mithilfe von Logikprogrammierung und Sprachen für die Einschränkungsauflösung schneller ausgeführt werden können .
Komplexe reaktive Systeme können sehr effizient mit speziellen synchronen Programmiersprachen wie Esterel programmiert werden , die sehr spezielle Kenntnisse über solche Systeme enthalten und sehr schnellen Code generieren.
Um ein extremes Beispiel zu nennen: Einige Sprachen sind hochspezialisiert, z. B. Syntaxbeschreibungssprachen, die zum Programmieren von Parsern verwendet werden. Ein Parser-Generator ist nichts anderes als ein Compiler für solche Sprachen. Natürlich ist Turing nicht vollständig, aber diese Compiler sind für ihre Spezialität außerordentlich gut: Sie produzieren effiziente Parsing-Programme. Da der Wissensbereich eingeschränkt ist, können die Optimierungstechniken sehr spezialisiert und sehr fein abgestimmt werden. Diese Parser-Generatoren sind normalerweise viel besser als das, was man durch das Schreiben von Code in einer anderen Sprache erzielen kann. Es gibt viele hochspezialisierte Sprachen mit Compilern, die exzellenten und schnellen Code für eine eingeschränkte Klasse von Problemen produzieren.
Daher kann es beim Schreiben eines großen Systems ratsam sein, sich nicht auf eine einzelne Sprache zu verlassen, sondern die beste Sprache für verschiedene Komponenten des Systems zu wählen. Dies wirft natürlich Kompatibilitätsprobleme auf.
Ein weiterer häufig wichtiger Punkt ist einfach die Existenz effizienter Bibliotheken für die zu programmierenden Themen.
Schließlich ist die Geschwindigkeit nicht das einzige Kriterium und kann im Widerspruch zu anderen Kriterien stehen, z. B. zur Codesicherheit (z. B. in Bezug auf fehlerhafte Eingaben oder Ausfallsicherheit bei Systemfehlern), zur Speichernutzung und zur Erleichterung der Programmierung (obwohl die Paradigmenkompatibilität tatsächlich hilfreich sein kann) ), Objektcodegröße, Programmwartbarkeit usw.
Geschwindigkeit ist nicht immer der wichtigste Parameter. Es kann auch verschiedene Erscheinungsformen annehmen, wie Komplexität, die durchschnittliche Komplexität oder Komplexität im schlimmsten Fall sein kann. Außerdem gibt es in einem großen System wie in einem kleineren Programm Teile, in denen die Geschwindigkeit entscheidend ist, und andere, in denen es wenig darauf ankommt. Und es ist nicht immer einfach, das im Voraus zu bestimmen.