Nashorn vs. Rhino vs. V8 – welche JavaScript-Engine ist schneller?

Hartmut Schlosser

Das JDK-8-Projekt Nashorn rollt das Thema JavaScript auf der JVM neu auf. Komplett neu implementiert, ECMAScript 5.1 kompatibel und dank Invokedynamic performant wie nie – mit diesen Werten soll die in die Jahre gekommene Rhino-Engine vergessen gemacht werden. Wie es um den letzten Wert – der Performanz der Nashorn Engine – tatsächlich bestellt ist, hat Ariya Hidayat in einem Benchmark-Test ergründet.

Die Vorteile von Nashorn liegen auf der Hand: Java und JavaScript lassen sich beide zusammen in einem Projekt auf der JVM einsetzen – Nashorn kompiliert den JavaScript-Code in Java-Bytecode, der auf der Java Virtual Machine ausgeführt wird. Das Einsatzgebiet von Nashorn erstreckt sich über Online-Interpreter in JavaScript mit REPL bis hin zu serverseitigen JavaScript-Frameworks mit Avatar.js (der Node.js-Implementierung für die JVM). Das alles macht natürlich nur dann Sinn, wenn die Ausführungsgeschwindigkeit stimmt – deshalb der Test durch Ariya Hidayat, der, wenn auch nicht streng wissenschaftlich, doch einen ersten Eindruck vermittelt:

Mittels des JavaScript-Parsers Esprima wird ein 268 KB großes jQuery-Projekt unter Nashorn, unter Rhino und zum Vergleich unter der V8-Engine ausgeführt. Hidayat geht es um zwei Aspekte: einmal um die fortlaufende Speicherallokation für die Syntax Nodes und einmal um die nicht lineare Code-Ausführung durch den rekursiven Abstieg beim Parsen.

Ergebnis: Kalt läuft Rhino schneller:

Rhino (kalt): 2607 ms

Nashorn (kalt): 5328 ms

Das Blatt wendet sich aber schnell – Nashorn beschleunigt bei den weiteren der 30 Durchläufe und liegt bald deutlich vor Rhino:

Rhino (warm): 824 ms

Nashorn (warm): 208 ms

Damit liegt Nashorn gar nicht weit von der V8-Engine, die mit 110 ms den Sieg in diesem Benchmark-Test davon trägt. Angesichts der kurzen Entwicklungszeit, die das junge Nashorn-Projekt im Vergleich zur ausgereiften V8-Engine vorzuweisen hat, und der Bürde, auf der Mutlisprachen-JVM aufzusetzen, ist das ein beachtliches Ergebnis.

Und bei rechtem Licht betrachtet ist die „Bürde“ JVM eigentlich ja die Stärke von Nashorn: Es harmoniert mit Java und erschließt sich die reiche Welt der Java-Klassenbibliotheken. Und darüber hinaus bettet es JavaScript in die polyglotte JVM und die Vielzahl anderer JVM-Sprachen ein. Gibt man Nashorn noch 2, 3 Jahre, dürfte der Performanz-Unterschied zur V8 weiter schrumpfen. Wir sind jedenfalls gespannt auf weitere Benchmarks! 

Als Subtext geht Nashorn übrigens als Referenzimplementierung einer dynamischen Sprache auf der JVM an den Start, um die Effizienz der neuen Invokedynamic-Konstrukte zu demonstrieren. Aus der Java Virtual Machine – JVM – wird eine Multi-Language VM – MLVM (das Ziel des Da Vinci Projects). Mehr Hintergründe zu Nashorn erfahren Sie hier auf JAXenter in dem Artikel „Java 8 & Nashorn: Der Weg zur polyglotten VM“ von Marcus Lagergren und Wolfgang Weigend.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: