Firefox überholt Google Chrome endlich bei SunSpider
(phoronix.com)- Firefox ist beim alten SunSpider-JavaScript-Benchmark schneller geworden als Chrome, doch dieser Test wurde inzwischen weitgehend durch JetStream ersetzt
- Die aktuellen Firefox Nightly News melden, dass Firefox bei SunSpider offenbar vor Chrome liegt, und die veröffentlichten Zahlen zeigen ebenfalls einen Vorsprung für Firefox
- Die Benchmark-Daten stammen von AreWeFastYet.com; verglichen wird ein etwa 10 Jahre alter JavaScript-Leistungstest
- Beim moderneren und anspruchsvolleren JetStream 2.0 liegt Google Chrome weiterhin klar vor Firefox
- Im vergangenen Monat hat Firefox neben der Ausführungsgeschwindigkeit von SunSpider auch mehrere weitere Verbesserungen umgesetzt, darunter die HTTP/2-Upload-Geschwindigkeit
Firefox liegt beim alten SunSpider vorn
- Die Mozilla-Entwickler bewerten positiv, dass Firefox im SunSpider-JavaScript-Benchmark bessere Ergebnisse erzielt als Google Chrome
- SunSpider ist ein rund 10 Jahre alter JavaScript-Benchmark, der inzwischen durch den JetStream-Benchmark ersetzt wurde
- In den aktuellen Firefox Nightly News heißt es: “We’re now apparently beating Chrome on the SunSpider JavaScript benchmark!”
- Die veröffentlichten Werte zeigen, dass Firefox in diesem alten JavaScript-Benchmark deutlich vor Chrome liegt
- Die Benchmark-Daten stammen von AreWeFastYet.com
In modernen Benchmarks bleibt Chrome vorn
- Im neueren und stärker fordernden JetStream 2.0-Benchmark liegt Google Chrome weiterhin klar vor Firefox
- Firefox hat die Ausführungsgeschwindigkeit des SunSpider-JavaScript-Benchmarks im Laufe des vergangenen Monats deutlich gesteigert
- Im gleichen Zeitraum wurden auch mehrere weitere Arbeiten umgesetzt, darunter die Verbesserung der HTTP/2-Upload-Geschwindigkeit
- Änderungen in den aktuellen Firefox-Nightly-Builds lassen sich in den Firefox Nightly News nachverfolgen
1 Kommentare
Meinungen auf Hacker News
Aus Sicht eines ehemaligen V8-Ingenieurs ist SunSpider ein miserabler Benchmark, und es ist kaum zu glauben, dass er immer noch verfolgt wird.
Er hat die Richtung der JavaScript-Performance-Entwicklung fast 15 Jahre lang in die Irre geführt und Engines dazu gebracht, seltsame Optimierungstricks zu bauen, die realen Websites nicht helfen.
V8 hat sich schon vor langer Zeit von den meisten Mikrobenchmarks gelöst: https://benediktmeurer.de/2016/12/16/the-truth-about-traditi...
Das heißt nicht, dass die Performance-Verbesserungen von Firefox unwichtig oder nicht erfreulich wären. Es heißt nur, dass SunSpider einer der schlechtesten Benchmarks ist, die man sich ansehen kann.
Die Kosten sind gering, und gelegentlich entdeckt er unbeabsichtigte Performance-Regressionen.
Auch das SpiderMonkey-Team stimmt voll und ganz zu, Mikrobenchmarks zu ignorieren. Es misst Speedometer hohe Bedeutung bei, weil er recht gut mit realer Performance korreliert, und schaut sich bei JetStream2 nur die benötigten Teile gezielt an.
Alles Ältere ist kein Ziel, sondern nur ein Messstab; wenn die Werte steigen, ist das schön, aber nur dann, wenn es ein Nebeneffekt von Arbeiten ist, die aus anderen Gründen gemacht werden.
Insbesondere die SunSpider-Verbesserung in dieser Grafik ist ein Nebeneffekt der Speedometer-Arbeiten, die dieses Jahr geleistet wurden.
https://news.ycombinator.com/item?id=36770883
Wenn man sich die Performance im Vergleich zu Chrome in den vergangenen zwölf Monaten über verschiedene Bereiche ansieht, ist es ermutigend, dass es in vielen davon kontinuierliche Verbesserungen gibt.
https://arewefastyet.com/win10/benchmarks/overview?numDays=3...
Warum sie gut sind, ist offensichtlich; schlecht sind sie, weil sie eine Feedback-Schleife erzeugen. Menschen entwickeln auf Performance hin, und die Performance wird für das verbessert, was Menschen entwickelt haben.
Ich frage mich, wie das V8-Team mit solchen Problemen umgegangen ist.
Das galt auch für V8; obwohl V8 zum Start ein eigenes Benchmark-Paket veröffentlichte, war dieses stark auf Property-Zugriffe ausgerichtet und deckte den Bereich des anfänglichen Seitenladens, den SunSpider zufällig behandelte, nur unzureichend ab.
Natürlich war das vor 15 Jahren, daher ist es schwer zu behaupten, dass ein damaliger Benchmark heute noch etwas Nützliches widerspiegelt; inzwischen hat er fast nur noch Wert zur Erkennung von Regressionen.
Auf allen meinen Computern und Smartphones nutze ich ausschließlich Firefox.
Bisher bin ich mit der Performance sehr zufrieden und hoffe aufrichtig, dass sie weiter verbessert wird. Wenn ich Firefox nicht verwenden kann, ist Brave meine zweite Wahl, Chromium die allerletzte.
Für Firefox empfehle ich diese Erweiterungen sehr: AdNauseam https://addons.mozilla.org/en-US/firefox/addon/adnauseam/, Consent-O-Matic https://addons.mozilla.org/en-US/firefox/addon/consent-o-mat..., Firefox Multi-Account containers https://addons.mozilla.org/en-US/firefox/addon/multi-account..., I don't care about cookies https://addons.mozilla.org/en-US/firefox/addon/i-dont-care-a...
Wenn man Avast nicht vertraut, wie weiter unten erwähnt, sollte man Consent-O-Matic besser meiden.
https://www.theregister.com/2022/09/21/avast_buys_i_dont_car...
Wenn man Avast nicht vertraut, wäre es wohl besser, auf den Fork I still don't care about cookies umzusteigen: https://github.com/OhMyGuus/I-Still-Dont-Care-About-Cookies
Es heißt also gleichzeitig: „Firefox schlägt Chrome in einem zehn Jahre alten JavaScript-Benchmark mühelos“ und „im neueren, anspruchsvolleren JetStream 2.0 schlägt Google Chrome Firefox weiterhin mühelos“.
Es sollte erwähnt werden, dass SunSpider seit 2013 nicht mehr aktualisiert wurde.
JetStream repräsentiert moderne JavaScript-Workloads besser, aber auch in diesem Benchmark schrumpft der Abstand.
Ich arbeite gerade mit der V8-Engine, und sie ist ein Minenfeld aus Deoptimierungen, bei dem unerwartete Dinge langsam werden
Die Struktur von Exception-Handlern kann die Performance-Eigenschaften des Codes stark verändern, und
async/awaitist wirklich fast Glückssache. Manchmal sind Promises schneller, manchmal sind async-Blöcke schnellerManche Verlangsamungen kann man auf schwache Spezifikationen schieben. Warum
...-Destructuring Iteratoren verwendet, verstehe ich nichtAllerdings frage ich mich, ob das V8-Team nicht eher Benchmarks hinterherläuft als realem Code, der nicht perfekt geschrieben ist
...keine Iteratoren verwenden könnte, wären insbesondere Generatoren deutlich weniger mächtigDass die V8-Performance in diesem Benchmark stagniert, liegt daran, dass sie sich schon lange nicht mehr darum gekümmert haben
Firefox hat leider einen Anreiz, sich darum zu kümmern. Denn selbst wenn Benchmarks nicht wichtig sind, sieht es trotzdem schlecht aus, wenn man zurückzufallen scheint
Ich meine, es gab einen neueren Beitrag, der dieses Thema mit Zahlen und Beispielen behandelt hat, aber ich kann ihn gerade nicht finden. Es könnte im chromium/chrome-Teamblog gewesen sein, vielleicht findet ihn jemand anderes
Weil in letzter Zeit viel darüber geredet wird, dass Chrome böse wird, habe ich ein paar Tage daran gefeilt, meine Chrome-Erweiterung IPvFoo auch in Firefox ordentlich zum Laufen zu bringen
IPvFoo ist ein Tool zur Beobachtung der IPv6-Umstellung. Technisch gab es sie seit 2017 auch für Firefox, aber es gab viele Kompatibilitätsbugs, bei denen ich gehofft hatte, Firefox würde sie irgendwann beheben
Am Ende habe ich mich entschieden, die verbleibenden Probleme zu umgehen, und jetzt ist Funktionsparität zwischen Chrome und Firefox auf einer gemeinsamen Codebasis erreicht: https://github.com/pmarks-net/ipvfoo
Firefox mit aktiviertem uBO ist über 100 % schneller als Chromium-basierte Browser
In Chromium-basierten Browsern funktioniert uBO wegen der Einschränkungen nicht richtig
Die Verbesserungen sind real
Ich habe gerade mit dem neuesten Speedometer 3.0 getestet, der noch nicht veröffentlicht, aber Open Source ist, und die jeweils aktuellen Versionen der Browser verwendet
Firefox Nightly(Gecko) 11.6, Safari TP(WebKit) 11.4, Chrome Canary(Blink) 9.9
https://github.com/WebKit/Speedometer
Ehrlich gesagt bleibt Firefox für mich nur zweite Wahl, bis die Debugging-Tools auf Chrome-Niveau sind und die Tab-UI etwas weiter verfeinert wird
Ich würde Firefox gern täglich nutzen, aber wenn ich es tue, habe ich das Gefühl, dass meine Entwicklungsgeschwindigkeit leidet
Das Firefox-Design gefällt mir nicht, aber das lässt sich mit Themes und Add-ons beheben
Ich habe das gemacht, um treestyletab so zu nutzen, wie ich es wollte, und wenn einem die UI wichtig ist, gibt einem userchrome.css ziemlich viel Freiheit
Außerdem synchronisiere ich es mit Nextcloud zwischen Geräten, sodass ich es nicht auf jedem Gerät einzeln ändern muss
Sie muss nicht auffällig sein; so schlicht wie das Standard-Chromium wäre völlig in Ordnung
Nachdem ich kürzlich eine Performance-Regression in Firefox gesehen hatte und einen Bugreport einreichen wollte, habe ich mich umgesehen, und Tools, die Performance recht öffentlich nachverfolgen, scheinen Beachtung zu finden
Dass man Tracing-Profile einfach hochladen und teilen kann, hilft ebenfalls: https://firefox-source-docs.mozilla.org/testing/perfdocs/ind...
Wenn man sich für die Firefox-Performance interessiert, hält ein eigener Blog einen auf dem Laufenden: https://blog.mozilla.org/performance/
Wenn man das Gefühl hat, dass Chromium auf einer bestimmten Website deutlich schneller ist, gibt es für einfache Meldungen https://webcompat.com/. Allerdings ist Bugzilla, selbst aus Sicht von jemandem, der GitHub Issues gewohnt ist, besser als gedacht