Ich denke, dass Leistungsoptimierung für viele Entwickler von Interesse ist, da sie mehr über verschiedene Möglichkeiten zur Erledigung einer Aufgabe lernen. Eine innere Stimme fragt: „Welcher Weg ist am besten?“ Zwar gibt es viele sich ändernde Metriken für „Beste“, wie Douglas Crockfords „JavaScript: The Good Parts“ aus dem Jahr 2008, aber die Leistung ist zugänglich, weil wir sie selbst testen können.
Es ist jedoch nicht immer einfach, die Leistung richtig zu testen und nachzuweisen.
Anfang der 2000er Jahre hatte der Internet Explorer die ersten Browserkriege gewonnen. IE war eine Zeit lang sogar der Standardbrowser auf Macs. Das einst marktbeherrschende Unternehmen Netscape wurde an AOL verkauft und schließlich geschlossen. Ihr Spin-off Mozilla befand sich in einer jahrelangen Betaphase für ihren neuen eigenständigen Browser Phoenix Firebird Firefox.
Im Jahr 2003 kam Opera 7 mit Presto heraus, einer neuen, schnelleren Rendering-Engine. Außerdem veröffentlichte Apple Safari, einen leistungsorientierten Browser für Macs, der auf der wenig bekannten Konqueror-KHTML-Engine basiert. Firefox wurde 2004 offiziell eingeführt. Microsoft veröffentlichte IE 7 im Jahr 2006 und Opera 9 veröffentlichte eine schnellere JavaScript-Engine. 2007 brachte Safari sowohl für Windows als auch für das neue iPhone. 2008 gab es Google Chrome und den Android-Browser.
Mit mehr Browsern und mehr Plattformen war die Leistung ein wichtiger Teil dieser Zeit. Neue Browserversionen verkündeten regelmäßig, dass sie der neue schnellste Browser seien. Benchmarks wie Apples SunSpider und Mozillas Kraken wurden in Veröffentlichungen häufig zitiert und Google unterhielt eine eigene Octane-Testsuite. Im Jahr 2010 führte das Chrome-Team sogar eine Reihe von „Geschwindigkeitstests“ durch, um die Leistung des Browsers zu demonstrieren.
Mikroleistungstests erregten in den 2010er Jahren große Aufmerksamkeit. Das Web verlagerte sich von eingeschränkter On-Page-Interaktivität hin zu vollständig clientseitigen Single-Page-Anwendungen. Bücher wie „High Performance JavaScript“ von Nicholas Zakas aus dem Jahr 2010 haben gezeigt, wie scheinbar kleine Designentscheidungen und Codierungspraktiken erhebliche Auswirkungen auf die Leistung haben können.
Schon bald befasste sich der JavaScript-Engine-Wettbewerb mit einigen dieser zentralen Leistungsprobleme bei Hochleistungs-JavaScript, und die schnellen Änderungen bei den Engines machten es schwierig, zu wissen, was im Moment das Beste ist. Angesichts neuer Browserversionen und mobiler Geräte waren Mikroleistungstests ein heißes Thema. Im Jahr 2015 war die inzwischen geschlossene Leistungstestseite jsperf.com so beliebt, dass es aufgrund von Spam eigene Leistungsprobleme gab.
Mit der Weiterentwicklung der JavaScript-Engines war es einfach, Tests zu schreiben, aber es war schwierig sicherzustellen, dass Ihre Tests fair oder sogar gültig waren. Wenn Ihre Tests viel Speicher verbrauchen, kann es bei späteren Tests zu Verzögerungen bei der Speicherbereinigung kommen. Wurde die Rüstzeit gezählt oder von allen Tests ausgeschlossen? Erzielten die Tests überhaupt das gleiche Ergebnis? War der Kontext des Tests von Bedeutung? Wenn wir !~arr.indexOf(val) vs. arr.indexOf(val) === -1 getestet haben, machte es einen Unterschied, ob wir den Ausdruck nur ausführten oder ihn in einer if-Bedingung konsumierten?
Als die Skriptinterpreter durch verschiedene Compiler ersetzt wurden, erkannten wir einige der Vorteile – und Nebenwirkungen – von kompiliertem Code: Optimierungen. Code, der beispielsweise in einer Schleife ausgeführt wird und keine Nebenwirkungen hat, kann vollständig optimiert werden.
// Testing the speed of different comparison operators
for (let i = 0; i < 10000; i += 1) {
a === 10;
}
Da hierbei ein Vorgang 10.000 Mal ohne Ausgabe oder Nebenwirkungen ausgeführt wird, könnte er bei der Optimierung vollständig verworfen werden. Es war jedoch keine Garantie.
Außerdem können sich Mikrooptimierungen von Release zu Release erheblich ändern. Die unglückliche Schließung von jsperf.com führte dazu, dass Millionen historischer Testvergleiche verschiedener Browserversionen verloren gingen, aber das können wir auch heute noch im Laufe der Zeit beobachten.
Es ist wichtig zu bedenken, dass Leistungstests der Mikrooptimierung mit vielen Vorbehalten verbunden sind.
Als die Leistungsverbesserungen nachließen, sahen wir, wie die Testergebnisse schwankten. Ein Teil davon waren Verbesserungen in den Engines, aber wir sahen auch Engines, die den Code für gängige Muster optimierten. Selbst wenn es besser codierte Lösungen gäbe, wäre es für Benutzer ein echter Vorteil, gängige Codemuster zu optimieren, anstatt zu erwarten, dass jede Website Änderungen vornimmt.
Schlimmer noch als die sich verändernde Browserleistung gab es im Jahr 2018 Änderungen an der Genauigkeit und Präzision von Timern, um spekulative Ausführungsangriffe wie Spectre und Meltdown abzuwehren. Ich habe einen separaten Artikel über diese Zeitprobleme geschrieben, falls Sie das interessiert.
Um die Sache noch komplizierter zu machen: Testen und optimieren Sie für den neuesten Browser oder den am wenigsten unterstützten Browser Ihres Projekts? Mit zunehmender Beliebtheit von Smartphones rückten auch Handheld-Geräte mit deutlich geringerer Rechenleistung in den Fokus der Überlegungen. Zu wissen, wo Sie Ihre Zeit für die besten Ergebnisse – oder wirkungsvollsten Ergebnisse – einsetzen sollten, wurde noch schwieriger.
Vorzeitige Optimierung ist die Wurzel allen Übels.
-- Donald Knuth
Dies wird häufig zitiert. Die Leute verwenden es, um zu suggerieren, dass wir, wenn wir über Optimierung nachdenken, wahrscheinlich Zeit verschwenden und unseren Code verschlechtern, um einen imaginären oder unbedeutenden Gewinn zu erzielen. Dies trifft wahrscheinlich in vielen Fällen zu. Aber hinter dem Zitat steckt noch mehr:
Wir sollten kleine Effizienzsteigerungen vergessen, sagen wir in etwa 97 % der Fälle: Eine vorzeitige Optimierung ist die Wurzel allen Übels. Dennoch sollten wir uns unsere Chancen bei diesen kritischen 3 % nicht entgehen lassen.
Das vollständigere Zitat fügt kritischen Kontext hinzu. Wir können viel Zeit in kleine Effizienzsteigerungen investieren, wenn wir uns das erlauben. Dies nimmt oft Zeit vom Ziel des Projekts ab, ohne einen großen Mehrwert zu bieten.
Ich persönlich habe viel Zeit in diese Optimierungen investiert, und im Moment schien es keine Verschwendung zu sein. Aber im Nachhinein ist nicht klar, wie viel dieser Arbeit sich gelohnt hat. Ich bin mir sicher, dass ein Teil des Codes, den ich damals geschrieben habe, die Ausführungszeit um Millisekunden verkürzt hat, aber ich kann nicht wirklich sagen, ob die eingesparte Zeit wichtig war.
Google spricht sogar von sinkenden Renditen bei der Einstellung der Octane-Testsuite im Jahr 2017. Ich empfehle dringend, diesen Beitrag zu lesen, um einen guten Einblick in die Einschränkungen und Probleme bei der Leistungsoptimierung zu erhalten, die bei Teams, die sich dieser Arbeit widmen, aufgetreten sind.
Wie können wir uns also auf diese „kritischen 3 %“ konzentrieren?
Wenn wir verstehen, wie und wann der Code verwendet wird, können wir bessere Entscheidungen darüber treffen, worauf wir uns konzentrieren müssen.
Es dauerte nicht lange, bis die Leistungssteigerungen und Variationen neuer Browser uns von dieser Art von Mikrotests abhielten und uns stattdessen auf umfassendere Tools wie Flammendiagramme konzentrierten.
Wenn Sie 30 Minuten Zeit haben, empfehle ich diese Chrome DevSummit-Präsentation 2015 über den V8-Motor. Es geht um genau diese Probleme... dass sich die Browser ständig ändern, und es kann schwierig sein, mit diesen Details Schritt zu halten.
Durch die Leistungsüberwachung und -analyse Ihrer laufenden Anwendung können Sie schnell erkennen, welche Teile Ihres Codes langsam oder häufig ausgeführt werden. Dies versetzt Sie in eine hervorragende Position, um Optimierungen in Betracht zu ziehen.
Durch die Verwendung von Tools und Bibliotheken zur Leistungsüberwachung können Sie sehen, wie der Code ausgeführt wird und welche Teile bearbeitet werden müssen. Sie geben uns auch die Möglichkeit zu sehen, ob verschiedene Bereiche auf verschiedenen Plattformen oder Browsern bearbeitet werden müssen. Möglicherweise ist localStorage auf einem Chromebook mit begrenztem Arbeitsspeicher und eMMC-Speicher viel langsamer. Möglicherweise müssen Sie mehr Informationen zwischenspeichern, um langsame oder lückenhafte Mobilfunkdienste zu bekämpfen. Wir können raten, was falsch ist, aber messen ist eine viel bessere Lösung.
Wenn Ihr Kundenstamm groß genug ist, profitieren Sie möglicherweise von RUM-Tools (Real User Monitoring), die Ihnen möglicherweise Aufschluss darüber geben, wie das tatsächliche Kundenerlebnis ist. Diese liegen außerhalb des Rahmens dieses Artikels, aber ich habe sie bei mehreren Unternehmen verwendet, um die Bandbreite der Kundenerfahrungen zu verstehen und meine Bemühungen auf die Leistung und Fehlerbehandlung in der Praxis zu konzentrieren.
Es ist einfach, sich mit der Frage „Wie kann ich dieses Ding verbessern“ zu befassen, aber das ist nicht immer die beste Antwort. Sie können viel Zeit sparen, indem Sie einen Schritt zurücktreten und fragen: „Ist das die richtige Lösung für dieses Problem?“
Probleme beim Laden einer sehr großen Liste von Elementen im DOM? Möglicherweise würde eine virtualisierte Liste, in der nur die sichtbaren Elemente auf der Seite geladen werden, das Leistungsproblem lösen.
Viele komplexe Vorgänge am Kunden durchführen? Wäre es schneller, einiges oder alles davon auf dem Server zu berechnen? Kann ein Teil der Arbeit zwischengespeichert werden?
Einen größeren Schritt zurückgehen: Ist dies die richtige Benutzeroberfläche für diese Aufgabe? Wenn Sie ein Dropdown-Menü mit zwanzig Einträgen entworfen haben und jetzt dreitausend Einträge haben, benötigen Sie möglicherweise eine andere Komponente oder Erfahrung, um eine Auswahl zu treffen.
Bei jeder Performance-Arbeit gibt es eine sekundäre Frage: „Was ist genug?“ Es gibt ein hervorragendes Video von Matt Parker von Stand-up Maths, in dem er über Code spricht, den er geschrieben hat, und wie seine Community ihn von Wochen Laufzeit auf Millisekunden verbessert hat. Obwohl es unglaublich ist, dass eine solche Optimierung möglich war, gibt es bei fast allen Projekten einen Punkt, an dem man „gut genug“ erreicht.
一度だけ実行するプログラムの場合、数週間は許容できるかもしれませんが、数時間の方が良いでしょう。しかし、それにどれだけの時間を迅速に費やすかが重要な考慮事項になります。
これは、エンジニアリングにおける 公差 のように考えることができます。目標もあるし、許容範囲もある。成功と完璧は同じではないことを理解しながら、完璧を目指すことができます。
目標は最適化の重要な部分です。現状が悪いということしかわかっていない場合、「より良くする」という目標は無制限です。最適化の目標がなければ、もっと重要なことに取り組むことができるのに、パフォーマンスや最適化をさらに高めるために時間を無駄にする可能性があります。
パフォーマンスの最適化は大きく異なる可能性があるため、これに関する適切な指標はありませんが、雑草の中で迷子にならないようにしてください。これは実際には、ソリューションのコーディングというよりもプロジェクト管理と計画に関するものですが、最適化の目標を定義する際には開発者の意見が重要です。 「代替案」セクションで提案されているように、修正は「高速化」ではない可能性があります。
マット・パーカーの場合、最終的には答えが必要であり、それ以外の目的でデバイスを使用する必要はありませんでした。私たちの世界では、訪問者のパフォーマンスとその予想される経済的影響と開発者/チームの時間と機会費用を測定することがよくあります。したがって、対策はそれほど単純ではありません。
カートに入れる時間を 50% 削減すると収入が 10% 増加するとわかっているとします。ただし、その作業を完了するには 2 か月かかります。 2 か月の最適化作業よりも大きな経済的影響を与える可能性のあるものはありますか?より短期間で何らかの利益を達成できるでしょうか?繰り返しますが、これはコードというよりもプロジェクト管理に関するものです。
コードを最適化する必要があるとわかった場合は、そのコードをプロジェクトの他の部分から分離できるかどうかを確認する良い機会でもあります。複雑な最適化を記述する必要があるため、コードを理解するのが難しくなることがわかっている場合、それをユーティリティまたはライブラリに抽出すると、再利用が容易になり、時間の経過とともに変更する必要がある場合にその最適化を 1 か所で更新できます。
パフォーマンスは紆余曲折を伴う複雑なテーマです。注意しないと、多くのエネルギーを費やしても実際的な利益はほとんど得られない可能性があります。好奇心は良い教師にはなりますが、必ずしも結果が得られるわけではありません。コードのパフォーマンスを試すことには利点がありますが、プロジェクトの実際の速度低下の原因を分析し、それらを解決するために利用可能なツールを使用することも必要です。
以上がJavaScript マイクロ パフォーマンス テスト、歴史、制限事項の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
