Entwicklung Firefox

Die meisten Optimierungen wie LTO oder PGO sind ja noch nicht aktiv, die Entwickler gehen davon aus das sämtliche Benchmarks nach der Aktivierung dieser positiv ist.

Zitat von Lurtz

Die Nightly für Windows von heute Nacht ist die erste, die mit Clang kompiliert wurde

Warum nur für Windows?
Mir ist die Relevanz dieser Plattform bekannt. Nur sollte beim Start einer neuen Umgebung der Test nicht gleich künstlich eingeschränkt werden.

Zunächst einmal sind das Kompilieren für Windows, macOS und Linux drei voneinander vollkommen unabhängige Baustellen. Überall den gleichen Compiler nutzen zu können, hat natürlich Vorteile, aber es hätte bei der Komplexität der ganzen Build-Infrastruktur nicht viel Sinn, eine Plattform von einer anderen abhängig zu machen. Das heißt, ob Mozilla die Windows-Versionen mit Clang kompiliert oder nicht, ist für macOS und Linux egal.

Eine Einschränkung liegt nicht vor. Auf macOS und Linux kann Firefox eh schon ziemlich lange mit Clang kompiliert werden. De facto zeigt mir Firefox auf macOS in about:buildconfig an, dass die macOS-Version auch mit Clang kompiliert ist. Für Linux müsstest du selbst prüfen, womit die offiziellen Mozilla-Builds (oder die deiner Distribution) kompiliert werden, das weiß ich nicht. Aber das Ergebnis würde mich interessieren, falls du nachsehen magst.

Aber wenn es um Linux geht, ist eines noch wichtig: Linux-Distributionen treffen hinsichtlich des Compilers sowieso ihre eigenen Entscheidungen für ihre Pakete und die nutzen für Firefox häufig eh nicht den gleichen Compiler wie Mozilla (selbst wenn es nur eine andere Version ist, es gibt meistens Unterschiede). Das heißt, wenn du Firefox von deiner Distribution beziehst, ist Mozillas Compiler-Wahl für dich eh nicht relevant. Firefox kann in jedem Fall auf jeder Desktop-Plattform mit Clang kompiliert werden, das ist nicht auf Windows beschränkt.

Mal kurz bei Mozilla nachgeschaut:

/builds/worker/workspace/build/src/gcc/bin/gcc -std=gnu99 	6.4.0 	-Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/builds/worker/workspace/build/src/gcc/bin/g++ 	6.4.0 	-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -O3 -fno-omit-frame-pointer

Und hier die Distribution:

/usr/bin/gcc -std=gnu99 	7.3.0 	-Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-security -Wformat-overflow=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
/usr/bin/g++ 	7.3.0 	-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-security -Wformat-overflow=2 -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O2 -fno-omit-frame-pointer

Beide nutzen gcc, nur lädt Mozilla einen älteren Compiler.
Aber ich kann es ja abwarten. Der Fx ist hier auch so schon schnell genug.

Danke für die Info, dann bin ich hier auch wieder up-to-date.

Ich habe mal nach Plänen für Linux gesucht. Interessanterweise hat Mozilla vor etwas mehr als einem Monat erst auch die lokalen Entwickler-Builds unter Linux von GCC auf Clang umgestellt:

https://bugzilla.mozilla.org/show_bug.cgi?id=1253064

Allerdings bislang nur diese und nicht die Release-Builds.

Auch danke an dich.

Und wie es sich gehört, ist Mozilla vorsichtig ohne Ende, denn sie möchten den Ruf nicht verlieren.

Hallo, kennt einer den Grund warum about:config -> "browser.showQuitWarning" in Firefox 63.0a1 nicht mehr vorhanden ist?
In Bugzilla.mozilla.org habe ich dazu keinen Hinweis gefunden. Ich habe diese Einstellung immer gerne auf true gestellt, weil ich gefragt werden wollte, ob die Session gespeichert werden soll oder nicht.
Gruß und Dank,
MrX1980

https://bugzilla.mozilla.org/show_bug.cgi?id=1474860#c3

Wow

Aber offenbar war der Wechsel auf Clang nur temporär gedacht https://bugzilla.mozilla.org/show_bug.cgi?id=1474756#c4.
Vielleicht überdenke sie es nochmals nachdem sie die positiven Veränderungen gesehen haben.

Zitat von MrX1980

Hallo, kennt einer den Grund warum about:config -> "browser.showQuitWarning" in Firefox 63.0a1 nicht mehr vorhanden ist?
In Bugzilla.mozilla.org habe ich dazu keinen Hinweis gefunden. Ich habe diese Einstellung immer gerne auf true gestellt, weil ich gefragt werden wollte, ob die Session gespeichert werden soll oder nicht.

Dazu gehört dieses Ticket:
https://bugzilla.mozilla.org/show_bug.cgi?id=1438499

Zitat von miku23

Aber offenbar war der Wechsel auf Clang nur temporär gedacht https://bugzilla.mozilla.org/show_bug.cgi?id=1474756#c4.
Vielleicht überdenke sie es nochmals nachdem sie die positiven Veränderungen gesehen haben.

Sie wollen definitiv dauerhaft Clang nutzen. Ein temporärer Wechsel zurück zu MSVC hat andere Gründe.

Zitat von Lurtz

Nutzt hier eigentlich jemand den Bookmark Mirror (services.sync.engine.bookmarks.buffer)? Ich habe den ein paar Wochen genutzt und jetzt wieder deaktiviert weil er noch sehr buggy ist (Bookmarks werden tlws. nach dem Verschieben wiederholt wieder in andere Ordner zurückverschoben oder dupliziert), zudem ist die Performance tlws. echt schlecht. Ich hatte Situationen mit einem starken i7 6700k, in denen ich mehrere Sekunden warten musste, bis das Dialogfeld zum Bookmarksetzen aufging. In der Zeit war die gesamte Bookmark-Funktion lahmgelegt.

Die Performanceprobleme sind mit dem Fix in der heutigen Nightly verschwunden

Siehst du, das Melden von Problemen kann sich lohnen. Vielleicht tut sich bei deinem zweiten Ticket ja auch noch was, ein bisschen Aktivität gab es da ja schon. Aber wegen der aktuellen Wartungsarbeiten (wenn ich gemein wäre, würde ich sagen: acht Stunden geplante Bugzilla-Downtime für ein paar Emojis :P) kann ich gerade nicht den aktuellen Status prüfen.

Offenbar, danke fürs Motivieren Sören Das andere Ticket habe ich ein wenig beobachtet, konnte das aber zuletzt nicht mehr beobachten. Könnte mir vorstellen dass es entweder ein Effekt beim Synchronisieren von Profilen mit Bookmark Mirror und ohne Bookmark Mirror ist, bzw. das mit dem anderen Ticket zusammenhing oder generell in dem Profil mit der Desktopinstallation irgendeine Form der Korruption vorliegt/lag.

Die automatische Installation von Updates kann immer noch über die Firefox-Einstellungen deaktiviert werden, aber die Option, nach Updates nicht einmal suchen zu lassen, wurde entfernt. Auch die dazugehörige Einstellung app.update.enabled in about:config existiert nicht länger. Das geht nur noch über die Policy Engine (wobei meine Erweiterung helfen kann: https://addons.mozilla.org/de/firefox/add…licy-generator/; auch wenn da steht, dass das nur mit Firefox ESR geht, das geht ab Firefox 62 auch im Mainstream-Firefox).

Aber ich kann nur betonen, dass es (bis auf ganz spezielle Ausnahme-Situationen) keinen guten Grund dafür gibt, Updates vollständig zu deaktivieren.

Firefox Nightly 63 unterstützt nun Version 1.0 des neuen AV1 Video-Codecs (wenn auch noch standardmäßig deaktiviert):
https://bugzilla.mozilla.org/show_bug.cgi?id=1445683

AV1 ist eine Riesen-Sache. Ein gegenüber H.264 deutlich überlegender Video-Codec, der dazu komplett lizenzfrei ist, was H.264 eben nicht war. Auch wenn wir als Nutzer für Videos nichts bezahlen müssen, dann häufig nur, weil andere Firmen Millionen dafür gezahlt haben. Mozilla sagt, dass das bei 80 Prozent aller Videos der Fall ist, die wir im Web betrachten. Um die Überlegenheit in ganz einfachen Zahlen auszudrücken: Mit AV1 bekommt man Videos mit vergleichbarer Qualität wie bei H.264 in etwa gerade mal der halben Dateigröße hin.

Entwickelt von der Alliance for Open Media, zu deren Gründungsmitgliedern nicht nur Mozilla zählt, sondern auch andere große Namen wie Google, Microsoft, Intel, Cisco, Amazon und Netflix, mittlerweile im Vorstand ergänzt von Apple, ARM, Facebook, IBM und Nvidia. Große Namen wie Adobe, hulu, VLC, Vimeo, Realtek, Vidyo, BBC und noch einige mehr haben sich ebenfalls angeschlossen. Also dass in diesem Codec die Zukunft liegt, davon kann ausgegangen werden. Ich sags's ja: große Sache. Daher meine Euphorie.

Zitat von Sören Hentzschel

[...] Ich sags's ja: große Sache. Daher meine Euphorie.

Das ist für alle von Vorteil. Schnelleres Streaming. Schnellere Downloads. Schnelleres Internet. Was will man mehr?

… und nicht zu vergessen für die Portale deutlich reduzierte Kosten, was uns indirekt ebenfalls betrifft. Können Kosten eingespart werden, müssen weniger nervende Maßnahmen ergriffen werden, um die Ausgaben zu decken und profitabel zu sein. Kommt das Geld nicht rein, muss es über Werbung und oder Bezahlmodelle reinkommen, im schlimmsten Fall führt es gar zur Schließung des Portals, weil die Verluste nicht mehr aufgefangen werden können. Selbst ein Riesen-Portal wie YouTube hat im Jahr 2015, also noch gar nicht lange her, vier Milliarden Dollar Umsatz und damit nicht einen Cent (!) Gewinn gemacht (Quelle: Wall Street Journal). Das sollte man also nicht unterschätzen, wie teuer der Betrieb einer solchen Plattform ist. Neben Google hätte sich das wohl kaum ein Unternehmen leisten können. Und ich glaube, auf YouTube will heute kaum noch jemand verzichten.

Ja, auf jeden Fall. Kein Wunder also, dass sich praktisch alle grossen Namen an der Entwicklung beteiligen.

Allerdings sind die Encoder bisher noch sehr langsam und der Hardwaresupport beim Decoding fehlt noch. Dennoch langfristig natürlich eine tolle Sache dass es breit unterstützte Konkurrenz zu HEVC gibt.