JavaScript Performance: Rhino vs. Spidermonkey

In den letzten Wochen hat sich einiges getan in Sachen JavaScript auf dem Server, siehe zum Beispiel John Resigs Posting “Bringing the Browser to the Server” oder mod_js. Die Idee ist mir schon seit einer Weile im Kopf rumgegangen: JavaScript eignet sich für Rapid Development und das Coding des Presentation Tier. In dem Maß, wie Web Applikationen zu “echten” Applikationen werden, sollte die Grenze zwischen Client und Server durchlässiger werden. Ganz abgesehen davon, dass JavaScript sexy ist. Die mit JavaScript 1.6 und 1.7 eingeführten Sprachfeatures wie Iteratoren, Generatoren und vor allem E4X haben es zu einer extrem interessanten Alternative zu etablierten Sprachen wie Java oder PHP werden lassen. Das größte Problem habe ich im Bereich der Performance erwartet, weswegen ich einige Testcases für einen kleinen Battle PHP vs. JavaScript geschrieben habe. Die Ergebnisse waren teilweise extrem überraschend, aber anders, als ich es erwartet habe.

Ich habe PHP 5.2.0, Spidermonkey JS 1.6.0 Final und Rhino 1.6R5 verwendet. Die beiden ersteren habe ich selber gebaut und Rhino als fertiges JAR verwendet. Als Java VM kam Java HotSpot (build 1.5.0_07-87, mixed mode, sharing) zum Einsatz. Getestet wurde das ganze auf einem 2 Ghz MacBook auf der Shell, indem ich meine Testfiles mit der Option -f spezifiziert habe. Die Zeitmessung wurde mit dem Kommando time durchgeführt, die angegebenen Werte sind jeweils die User Time. Die Testfiles wurden so identisch wie möglich implementiert, d.h. es kamen keine sprachspezifischen Erweiterungen zum Einsatz (für Test 2 hätte sich in JavaScript z.B. die Verwendung von Generatoren/Iteratoren angeboten).

Test PHP 5.2.0 Rhino Spidermonkey
Test 1: 10^8 mal ein wenig Arithmetik in einer Schleife 0m25.427s 1m33.396s 1m7.248s
Test 2: Berechnung der Fibonacci Reihe von 10, 10^6 Wiederholungen, rekursiv implementiert 0m30.410s 0m7.376s 0m16.689s
Test 3: 2 Klassen definiert, eine abgeleitete, 10^6 Wiederholungen: Instanz erzeugt, Superklassen Konstruktur aufgerufen, danach ein Boolscher Test und eine String-Verkettung. 0m9.451s 0m4.061s 0m9.992s

Ich muss sagen, dass ich von den Ergebnissen extrem überrascht bin. Ganz besonders bei Test 2 und 3 im Vergleich zu Spidermonkey und Rhino. Um das nochmal zu verdeutlichen: für Rhino muss eine Java VM initialisiert, das JAR eingelesen und die JavaScript Engine gestartet werden. Und trotzdem ist die Ausführungszeit für die Tests um mehr als Faktor 2 kleiner als für die in C implementierte Engine?! Auch wenn die verwendete Java VM einen Just-In-Time compiled, kann das doch wohl kaum schneller sein. Das muss mir mal bitte jemand erklären. Übersehe ich was?

4 Kommentare zu „JavaScript Performance: Rhino vs. Spidermonkey“

  1. Herbert Rusznak sagt:

    hi du,
    viel interessanter als irgenwelche arithmetischen operationen auf der serverseite (wer braucht schon einen webdienst der fibonacci reihen berechnet?) sind imho stringroutinen. kaum eine (lese: keine) webseite kommt ohne strings aus :)

    ich schätze generell alles was mit methodenaufrufen zu tun hat, nach einer gewissen aufwärmzeit der jvm, schneller auf der jvm ein (im prinzip deine 2 letzten tests), da sie ja diese sachen (vor allem bei 10 aufrufen) “inlinen” können sollte -> da werden die einfach wegoptimiert. spidermonkey kann sowas nicht können.

    wie gesagt, umfangreichere tests wären schön, ev. auch mit zweckentfremdeten standardbibliotheken von der clientseite ( z.b. prototype oder dojo )

    lg
    herby

  2. Claus sagt:

    Hallo Herbert,

    danke für den Kommentar (gut, dass es nicht wieder ein Viagra-Spam war, der durch Akismet geschlüpft ist ;-) . Ich wollte das ursprünglich ganicht so hoch hängen, d.h. mich hat vor einer Weile interessiert, wie sich die Sprachen und die unterschiedlichen Implementierungen überhaupt so schlagen. Fibonacci-Reihen auf dem Server sind sicher nicht so sinnvoll. Weitere Tests sind aber in Vorbereitung, wo ich mir vor allem die DOM-Performance anschauen möchte. Die Entwicklungen der letzten Monate und Wochen sind wirklich aufregend, z.B. Stichwort Jaxer von Aptana.

    Gruss,
    Claus

  3. Yurtdisi Egitim sagt:

    mein Deutsch ist nicht guti is it availible in English

  4. Claus sagt:

    Hi,

    no, unfortunately at this time not. I always planned to do that, but I’m continuously postponing it since I don’t have time.

    Cheers,
    Claus

Kommentieren