Ich versuche, First Contentful Paint (FCP) und Largest Contentful Paint (LCP) mit diesen beiden PRs zu verbessern:
Ich bin wirklich an den tatsächlichen Auswirkungen dieser Änderungen interessiert – probieren Sie es bitte aus und geben Sie Feedback.
Und natürlich ist jede Hilfe beim Testen, Refactoring und der Testabdeckung mehr als willkommen.
Der erste sieht nach einer einfachen Optimierung aus, die meiner Meinung nach sinnvoll ist. @david und @eviltrout haben Zeit damit verbracht, diesen Bereich zu optimieren, daher bin ich sehr gespannt, was sie dazu sagen.
Der zweite fühlt sich langfristig etwas fragiler an. Ich verstehe den Wunsch zu optimieren vollkommen, aber er macht mir ein wenig Sorgen, da er ein Bereich sein wird, den wir pflegen müssen.
Hallo @rrit - danke für die PRs. Die erste klingt nach einer guten Verbesserung. Konntest du die Auswirkungen auf die Leistung messen? Wie viel Zeit spart sie?
Wie @sam sagte, ist die Wartbarkeit der zweiten etwas besorgniserregend. Sieht so aus, als wäre sie kopiert und eingefügt aus dem Ember-Quellcode? Hast du etwas geändert, um die Leistung zu verbessern?
Implementiert jetzt über Map anstelle von Array.
Zeitaufwand beim Anwendungsstart in lookupView – für Entwicklungsinstand:
ohne Patch: 124 ms
Firefox Profiler (Callstack gefiltert nach lookupView)
mit Patch: 9 ms
Firefox Profiler (Callstack gefiltert nach lookupView)
Gesparte Zeit: ~115 ms
Dies reduziert die Zeit, die in appendOutletView verbracht wird, von 1.083 ms auf 946 ms – für Entwicklungsinstand.
Ja, es ist tatsächlich ein Copy-Paste mit einer Änderung: eine günstige Prüfung für isPath verwenden.
// ersetzt @ember/-internals/utils isPath
// @siehe: https://github.com/emberjs/ember.js/blob/3537670c14883346e11e841fcb71333384fcbc87/packages/%40ember/-internals/metal/lib/path_cache.ts#L5-L7
// @siehe: https://github.com/emberjs/ember.js/blob/255a0dd3c7de1187f4a2f61a97cf78bfff8f66a8/packages/%40ember/-internals/glimmer/lib/utils/bindings.ts#L70
let isPath = context.indexOf('.') > -1;
Z. B. löst renderTopicListItem letztendlich viele Aufrufe von _getPath aus (weitere 50-100 ms Einsparung):
Firefox Profiler (Callstack gefiltert nach _getPath innerhalb von renderTopicListItem)
Vielleicht sind die aufwändigen Aufrufe von _getPath etwas, das in Ember.js und nicht in Discourse optimiert werden sollte.
Und werfen Sie einen Blick auf den Firefox Profiler, um Einblicke in die JavaScript-Ausführung zu erhalten:
Danke für die Patches. Der zweite scheint etwas anfällig zu sein.
Laufen Ihre Benchmarks im Entwicklungs- oder Produktionsmodus? Ember hat in beiden ein ganz anderes Profil.
@david hat einen ausgezeichneten Weg gefunden, dieses Problem zu beheben – siehe seinen Kommentar auf GitHub.
Die Zeit für Aufrufe von renderTopicListItem auf der Webseite ‘latest’ sinkt in einem Ember ‘production’-Build von 348 ms auf 201 ms.
Die früheren Benchmarks liefen noch im Entwicklungsmodus.
# Ember im Produktionsmodus starten
d/ember-cli server --environment="production"
Leider konnte ich diese große Geschwindigkeitssteigerung nicht reproduzieren. Unter Firefox und Chrome (macOS) sehe ich keine messbare Verbesserung. Chrome benötigt etwa 23 ms für renderTopicListItem. Firefox 30 ms. Auf einem älteren Android-Gerät (Pixel 3) sehe ich etwa 108 ms. Die Zahlen scheinen sich vor/nach der Änderung nicht zu ändern.
Übrigens habe ich diese Zahlen mit der Performance API gemessen. Ich habe performance.mark("rtli-start") am Anfang von renderTopicListItem und dann performance.measure("rtli", "rtli-start") am Ende hinzugefügt.
Dann lade ich den Browser neu mit geschlossenen Entwicklertools und deaktivierten Browser-Plugins (Entwicklertools und Browser-Plugins können die Rendering-Leistung erheblich beeinträchtigen). Dann, nach Abschluss des Ladens, öffne ich die Entwicklertools und führe dies aus, um die Messungen zusammenzufassen:
performance.getEntriesByName("rtli").reduce((v, m) => v + m.duration, 0);
Wir werden diese Änderung auf jeden Fall zusammenführen – es ist eindeutig eine bessere Implementierung. Aber ich bin mir nicht sicher, ob sie uns einen sichtbaren Unterschied in der Rendering-Leistung bringen wird 
Ich kann die Leistungsvorteile immer noch mit der Performance API im Firefox-Privatmodus (Linux) reproduzieren.
Testen von http://localhost:4200/latest
Die Zeit, die in renderTopicListItem verbracht wird, ist von ca. 290 ms auf ca. 190 ms gesunken.
Meine Discourse-Testinstanz hat viele Themen mit vielen Antworten und vielen verschiedenen Autoren – Daten, die aus einer produktiven Instanz gezogen wurden. Dies führt zu vielen zu rendernden Elementen.
Vielleicht ist das der Unterschied in unseren Benchmarks?
Discourse rendert 30 Themen auf der Seite „latest“ vor. Dann wird der Inhalt zum ersten Mal angezeigt (FCP). Oberhalb des sichtbaren Bereichs sind nur ca. 12 Themen sichtbar.
Dasselbe gilt für eine Themen-Seite: 20 Beiträge werden vorab gerendert, aber maximal 6 einzeilige Beiträge sind oberhalb des sichtbaren Bereichs sichtbar.
Dies könnte ein weiterer Optimierungspunkt für FCP sein.
Könnten Sie bitte die Firefox- und Betriebssystemversion mitteilen? Die 290-ms-Zahl ist fast dreimal langsamer als bei einem Android-Gerät von 2018, was etwas überraschend ist.
Das könnte einige der Unterschiede erklären, ja. In meinem Fall habe ich sie mit Live-Daten von Meta ausgeführt:
bin/ember-cli --environment production --proxy https://meta.discourse.org
Ja, das ist eine mögliche Verbesserung. Wir müssen jedoch sehr vorsichtig sein, dass das Layout und/oder das Scrollen nicht springt (z. B. wenn der Benutzer die Seite aktualisiert, während er bereits zur Hälfte nach unten gescrollt ist). Die Definition von „unterhalb des sichtbaren Bereichs“ variiert auch je nach Gerät/Browser/Theme.
Leider schlägt die Ausführung von Ember mit einem Proxy bei mir fehl:
d/ember-cli --environment production --proxy https://meta.discourse.org
Discourse Build Error
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP stimmt nicht mit den alternativen Namen des Zertifikats überein:
Host: localhost. ist nicht in den alternativen Namen des Zertifikats enthalten: DNS:*.cdck-prod-meta.discourse.cloud
Discourse Build Error
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP stimmt nicht mit den alternativen Namen des Zertifikats überein:
Host: meta.discourse.org. ist nicht in den alternativen Namen des Zertifikats enthalten: DNS:*.cdck-prod-meta.discourse.cloud
Extrahierte Daten aus Firefox about:support
|Name |Firefox|
|—|—|
|Version |95.0.2|
|Build-ID |20211219102529|
|Distributions-ID |canonical-002|
|User-Agent |Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0|
|Betriebssystem |Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10)|
|Betriebssystem-Theme |Adwaita-dark / Adwaita|
|Anwendungsprogrammdatei |/snap/firefox/777/usr/lib/firefox/firefox|\
|Name |Firefox Developer Edition|
|—|—|
|Version|96.0b10|
|Build-ID|20211228195952|
|Update-Verzeichnis|/opt/firefox-dev-autoinstall|
|Update-Kanal|aurora|
|User-Agent|Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0|
|Betriebssystem|Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10)|
|Betriebssystem-Theme|Adwaita-dark / Adwaita|
|Anwendungsprogrammdatei|/opt/firefox-dev-autoinstall/firefox-bin|\
Extrahierte Daten aus Chromium chrome://system/
|CHROME VERSION|90.0.4430.212 built on Debian 10.9, running on Debian 10.11|
| — | — |
|OS VERSION|Linux: 5.10.0-0.bpo.9-amd64|\
OS version:
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
Der PR für das Refactoring wurde nun gemerged:
Danke, dass du das hier angesprochen hast, @rrit – es ist eine schöne Verbesserung!
Dieses Thema wurde nach 9 Stunden automatisch geschlossen. Neue Antworten sind nicht mehr möglich.