9. Januar 2009
keine kommentare
Dromaeo hat vor kurzem ein neues Testverfahren eingeführt. Statt der benötigten Zeit für die Tests, wird nun gemessen, wie viele Durchläufe durchschnittlich pro Sekunde in einer fest definierten Zeit erreicht werden. Das macht die ganze Sache langwieriger, aber auch genauer und sagt wesentlich mehr über die Leistungsfähigkeit einer Javascript Engine aus.
Statt auf zwei unterschiedlichen Systemen zu messen, habe ich nun unterschiedliche Benchmarks gewählt: Dromaeo Javascript Test (Mozilla.org), SunSpider Javascript Test (Webkit-Team) und V8 Javascript Test (Google).
Testsystem: Intel Core 2 Duo E8400, 2 GB RAM, Windows XP SP 3
Ein Bild sagt mehr als 1.000 Worte. Chrome deklassiert alle anderen Browser, nur im hauseigenen V8-Test ist das aktuelle Webkit Nightly Build einen Tick schneller. Wie üblich sind die Entwickler-Versionen ihren aktuellen Final-Kollegen deutlich voraus, und die Javascript-Leistung des Internet Explorers, sofern er sich überhaupt testen lies, ist ein schlechter Scherz.
Ein blamables Ergebnis für Microsoft, das mit dem IE 8 auch nicht großartig besser werden wird. Wenn man sich in Redmond angesichts solcher vernichtenden Benchmarks nicht endlich im Zugzwang sieht, sind sie entweder blind und/oder blöd. Google treibt die Entwicklung mit großen Schritten voran, während nur Webkit bzw. Apple halbwegs mithalten kann. Mozilla.org und Opera müssen sich sehr anstrengen, um wieder Anschluss zu finden.
Und Microsoft? Tja, ich sehe nur zwei Möglichkeiten: den ganzen alten IE-Quellcode öffentlich verbrennen und komplett neu schreiben, oder man setzt in Zukunft auf Webkit/Squirrelfish bzw. Webkit/V8 oder Gecko/Tracemonkey.
4. Januar 2009
keine kommentare
Oder anders gesagt: Benchmarks von Squirrelfish, V8 und Tracemonkey mit Hilfe von dromaeo.com.
Testsystem: Intel Core 2 Duo P8600, 2 GB RAM), MacOS X 10.5.6 (MacBook Pro 15" 2,4 GHz Late 2008)
Testystem: Intel Core 2 Duo E8400, 2 GB RAM, Windows XP Service Pack 3
Das Squirrelfish schnell ist, war ja schon bekannt. Aber das es V8 und Tracemonkey dermaßen in den Hintern tritt, hätte ich nicht gedacht. Auf die Antwort von Mozilla und Google dürfen wir alle gespannt sein.
Anmerkung zum Internet Explorer: leider konnte ich weder den IE 6 noch 7 dazu bewegen, überhaupt einen Benchmark durchlaufen zu lassen. Entweder meldete er Javascript-Fehler oder stürzte ab. Aus Tests von anderen Leuten, ist aber bekannt, dass er im Vergleich extrem langsam ist – im Schnitt etwa 10 – 15 Sekunden.
Während bei Safari der Taktenraten- und Cache-Unterschied sich noch halbwegs realistisch in den Ergebissen von OS X und Windows widerspiegelt, zeigt sich bei Firefox, dass Mozilla die Mac-Version noch weiter optimieren sollte.
Update: Nun mit Diagrammen statt Text-Ergebnissen.
5. September 2008
kommentare (3)
Die Katze ist nun seit ein paar Tagen aus dem Sack und ich kann das dauernde Lamentieren über Datenschutz und Spionage nicht mehr hören. Bei einem Open Source-Projekt ist so eine Diskussion überflüssig. Jeder kann sich den Quelltext herunterladen und prüfen. Google Suggest in der Adressleiste lässt sich abschalten und die Browser-ID ebenso umgehen – letztere nutzt übrigens auch Mozilla Firefox beim Auto-Update …
Leider geht die technische Seite in diesem Theater etwas unter. Dabei ist gerade das doch die Stärke von Chrome. Eine virtuelle Maschine (im Sinne einer Java-VM) für Javascript, die dazu keinen Bytecode, sondern gleich x86-Code generiert, hat massive Geschwindigkeitsvorteile und ist durch Einkapselung auch noch sicherer. Zumindest solange keine schwerwiegenden Fehler auftreten, die es erlauben ins eigentliche Betriebssystem einzudringen.
Letztendlich wird es aber zur Philosophiefrage werden, ob man nun einen normalen Interpreter oder eine kompilierende VM benutzt. Als reiner Interpreter wird Tracemonkey in Firefox 3.1 wohl gleich auf liegen. Allerdings sind Tracemonkey, Squirrelfisch und V8 noch neu, so ist sicher noch viel Luft nach oben.
Dass die Wahl der Render Engine dagegen auf Webkit fiel, ist schon etwas verwunderlich. Schließlich ist Google der Hauptgeldgeber der Mozilla Foundation und es bleibt die Frage: warum nicht Gecko? Als Grund wurden die guten Erfahrungen mit Webkit während der Entwicklung von Android und geringer Ressourcenhunger angeführt.
Soweit so richtig, aber ich glaube eher, dass Mozilla nicht dem Tempo folgen kann, welches Google vorschwebt und man sich daher gegen Gecko entschiedt. Neue Firefox- und Thunderbird-Versionen verzögern sich meist gewaltig. Bei den anderen Projekten wie z.B. Sunbird, sieht es auch nicht besser aus.
Chrome soll offensichtlich ein schneller Schlag gegen Microsoft bzw. den Internet Explorer werden. Aus meiner Sicht als beruflicher Web-Entwickler, kann ich das nur befürworten. Die Jungs aus den Redmond müssen endlich ganz aus ihrem Dornröschenschlaf aufwachen. Zwar hat sie Firefox geweckt, aber noch taumeln sie schlaftrunken durch die Gegend.
Nach fünf Jahren absolutem Stillstand (2001 - 2006) und auch dem IE 7, muss endlich mehr passieren. Version 8 ist ein richtiger Schritt, aber Microsoft hat sicher mehr Möglichkeiten, als mehr schlecht als recht mit Gecko, Presto und Webkit gleichziehen zu können. Wir mussten und müssen uns in der Branche immer noch mit den Hinterlassenschaften dieser technischen Stagnation rumschlagen. Das kann und darf so nicht mehr weitergehen.
Darum wünsche ich Google viel Erfolg, auch wenn ich vorerst bei Firefox bleiben werde. Es gibt einfach zu viele Extensions, die inzwischen unverzichtbar geworden sind – zumindest für uns Entwickler.
