So ganz schlüssig finde ich die Verläufe nicht. Nightly ist nicht per se langsamer als Beta, das sind nur spezielle Builds, die langsamer wären aber nicht auf dem Nightly Channel verteilt werden.
Entwicklung Firefox
-
pcinfarkt -
15. August 2009 um 20:46 -
Erledigt
-
-
Sagen wir mal so: wenn eine Nightly-Version und eine Beta-Version vom Code her den absolut gleichen Stand haben, dann sind Beta-Versionen etwas schneller, weil sie im Gegensatz zu Nightly-Versionen PGO [1] aktiviert haben. Das wirkt sich auch auf Speedometer aus.
[1] https://en.wikipedia.org/wiki/Profile-guided_optimization
-
Achso, Nightlys haben noch kein PGO? Das erklärt einiges
Wieso macht man das bei der Nightly nicht, weil es zu aufwändig wäre PGO für Versionen zu verwenden, die zwei Mal täglich kompiliert werden müssen?
Weiß hier jemand ob Chrome Canary PGO verwendet?
-
Weil sich PGO nicht so gut zum debuggen eignet
-
Gibts zum Debuggen nicht sowieso noch spezielle Builds?
-
Ich bin ja erst seit einigen Tagen wieder eingestiegen was Fx angeht und habe das bisher auch nicht bereut, da ich ich das Design und die Performance seit v57+ als überzeugend empfinde.
Was mich allerdings irritiert ist dieser Speedometer-Test samt Vergleich mit Chrome. Wenn ich das richtig mitbekommen habe, soll Fx in diesem Test nahe an Chromes Leistung herankommen. Auf meinem System (Surface Book) kann ich das allerdings nur bedingt nachvollziehen: Fx schließt hier mit 33,58 Durchläufen pro Minute ab, während Chrome einen Wert von 50,60 erreicht. Das ist m. E. ein deutlicher Abstand. Ich vergleiche hier übrigens das aktuelle Fx Nightly mit dem aktuellen Release von Chrome. Der aktuelle Canary Build von Chrome liegt allerdings auf dem gleichen Niveau.
Habe ich hier etwas verpasst oder missverstanden?
-
Mit neuem Profil für beide Browser hast du es getestet?
Die Tests beziehen sich wohl auf FF57 vs Stable Chrome; du solltest also die gleichen Browser nehmen. -
Quantum hatt auch gerade erst bekonnen es wird in naher zeit noch mehr funktionen kommen die den browser weiter beschleunigen werden.Ein paar sachen kann schoN TUSTEN WAS ICH ABER NICHT EMPFHELE WEGEN TEIL STARKER INSTABILITÄTEN:
SRY WEGEN DER GRO?SCHREIBUNG ABER MEINE TASARTUR HATT MA WIEDER EIN KLEINEN SCHADEN:
-
https://bugzilla.mozilla.org/show_bug.cgi?id=1404344
Ich find's ja interessant, dass Mozilla Ressourcen investiert, damit ein Downgrade speziell von Firefox 57 auf Firefox 56 keinen Schaden am Profil anrichtet…
-
Erwartet man so viele User, die nicht wechseln wollen?
-
das macht üperhaupt keinen sinn da es für firefox 56 keine sicherheitsupdates mehr kommen .
-
beastman665: ob es vernünftig ist, Firefox 56 zu nutzen, wenn Firefox 57 veröffentlicht ist, ist ein vollkommen anderes Thema als die Realität es ist.
Tatsache ist, dass mit Firefox 57 sehr viel anders sein wird, und Tatsache ist auch, wenn man in die Vergangenheit schaut, dass es Nutzer gibt, die alte Versionen nutzen. Setzt man beides zusammen, dann kommt man dahin, dass auch, wenn Firefox 57 ein toller Release wird und viele zufriedene Nutzer haben wird, es wahrscheinlich auch mehr Nutzer geben wird, die erst einmal bei Firefox 56 bleiben, als dass es bei vorherigen Updates der Fall so war.
Damit kann man als Browserhersteller auf verschiedene Weisen umgehen. Eine Möglichkeit ist, diese Realität zu ignorieren und knallhart zu sagen, Downgrades wurden noch nie unterstützt, dein Profil ist kaputt, leb damit. Oder man baut eine Sicherheit ein, damit diese Nutzer zumindest Firefox weiter nutzen können und vielleicht später auf eine aktuelle Version umsteigen und nicht den Browser dann komplett wechseln, weil auch Firefox 56 nicht mehr richtig funktioniert.
Eben weil Firefox 57 so einen großen Unterschied macht wie bisher noch nie ein Firefox-Update, ist das eine Überlegung wert und Mozilla hat sich offensichtlich dafür entschieden. Kann man gut finden, kann man unnötig finden, aber Sinn ergibt es schon.
-
ich hatte mir schon länger gedanken gemacht warum sie firefox 56 nicht zur esr machen.
-
Gegenfrage: wieso sollte Mozilla Firefox 56 zu einer ESR-Version machen? Firefox ESR 52 kann damit nicht abgelöst werden, das ist vollkommen ausgeschlossen, weil an ESR-Versionen ein Support-Versprechen geknüpft ist. Eine zusätzliche Version, die ebenfalls parallel angeboten wird, kostet grundsätzlich schon Ressourcen. Und wenn man dann noch überlegt, was Firefox 57 für Änderungen bringt, unter anderem die Nicht-Unterstützung von Legacy-Erweiterung, bedeutet deine Idee mehrere Monate, die Mozilla das alles weiter unterstützen muss. Das bindet Massen an Ressourcen, nicht nur für die Entwicklung von Firefox, auch addons.mozilla.org und was da noch alles dran hängt.
-
Mozilla experimentiert mit einer kleineren Tab-Mindestgröße:
https://bugzilla.mozilla.org/show_bug.cgi?id=1404465Ich finde es grässlich, einer der Gründe warum Chrome nie mein Standardbrowser wurde war die furchtbare Tableiste. Hoffentlich bleibt das optional...
Nach dem Test mit 50 als Wert für die Mindestbreite geht man jetzt wohl mit 76. Wie ist der Wert für dich? Ich hatte verschiedene Größen getestet, allerdings nur in Zehnerschritten, und Mozilla das Feedback gegeben, dass ich 80 als Minimum sehe. 76 ist näher an der 80 als an der 70, daher würde ich mit dem Wert vermutlich klarkommen. Ich werde es ein paar Tage lang testen, wenn es umgesetzt ist, und andernsfalls eben die Einstellung nutzen, wenn es nicht geht. Aber es ist schon ein Unterschied zu 50, daher gebe ich dem Ganzen eine Chance.
-
76 finde ich gerade noch ok, könnte ich tolerieren, würde ich aber für mich nicht als Optimum sehen. Es kam auch schon die Anmerkung, dass der Touch-Mode mindestens 82 bräuchte, da die Schließen-Schaltfläche sonst zu groß für den Tab wird.
-
Retaining Display Lists wird in ein oder zwei Wochen in der Nightly landen:
Zitat[...]performance data,
which is showing some really big wins, including a 77% reduction in
display list building time on YouTube when we manage to do a partial
update. These are just preliminary results, and we have a lot of
remaining plans to build off this architecture and get further wins.
https://groups.google.com/forum/#!topic/…orm/jSuLiuXqs8wMeta-Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1352499
-
Lin Clark hat mal wieder einen fantastischen Artikel geschrieben, diesmal über WebRender: https://hacks.mozilla.org/2017/10/the-wh…ts-rid-of-jank/
-
Ihre Artikel sind wirklich ein Vergnügen! Da steckt aber auch verdammt viel Arbeit drin…
ZitatI was researching casually (an hour here or there) for about three months. Then I started the really in-depth, focused research and beginnings of the draft about a month ago.
---
Nachdem https://bugzilla.mozilla.org/show_bug.cgi?id=1403077 gelandet ist, kann Mozilla nun Stylo für einzelne Webseiten deaktivieren, und zwar ganz einfach, indem Mozilla serverseitig die Konfiguration anpasst. Das heißt, wenn sich nach der Veröffentlichung von Firefox 57 herausstellt, dass eine Webseite mit Stylo nicht korrekt dargestellt wird, kann Mozilla darauf reagieren, ohne ein Update für Firefox veröffentlichen zu müssen. Eine ziemlich gute Maßnahme zur Risiko-Minimierung bei so einem gewaltigen Projekt, die gesamte CSS-Engine auszutauschen.
https://bugzilla.mozilla.org/show_bug.cgi?id=1356654#c6 zeigt schön, wie viel der Compiler ausmacht. Nur durch die Verwendung von Visual Studio 2017 statt 2015 können noch einmal knapp sechs Prozent in Speedometer herausgeholt werden. Das ist aber erst für nach Firefox 57 ein Thema.
-
gibts das auch für die nightly?Mozilla testet aufgebohrte Adressleiste in Firefox 56, powered by Cliqz