Ember.js: バージョン2.Xと3.Xの間のパフォーマンスの低下

私のマシンのChrome81で数回実行した後、次のようになりました。

2.18ベストタイム：283ms
3.18ベストタイム：471ms

それは、DevToolsを閉じた状態で実行していました。

次に、次の方法で3.18twiddleをEmberOctaneに変換しました。

• コンポーネントとコントローラーにネイティブクラスを使用する。
• @trackedを使用し、 @computedを使用しない。
• t-rコンポーネントは、バッキングクラスを必要としないため、テンプレートのみのコンポーネントに変換します。
• コンポーネントを呼び出すときに山かっこ構文を使用する。
• テンプレートで適切な場合は、名前付き引数とthis.します。

その後、3.18.1から得たベストタイムは276msだったので、2.18の数値に沿って有意義な改善が見られました。

ただし、これらのパフォーマンステストは特に科学的なものではなく、パフォーマンスの観点からどの変更が最も重要であるかについては調査していません。

ひねりでのプロファイリングはかなりエラーが発生しやすいですが、プロファイリングするために通常のember-cliアプリリポジトリに移植できますか（2つのバージョンのそれぞれにブランチを使用）？

@rwjblue通常のember-cliアプリでも同じ結果が得られます。 ここでテストでき

@ richard-viney考慮すべき改善点があるかもしれませんが、問題は、両方のバージョンで非推奨のコードが使用されておらず、パフォーマンスの低下が許容できないように見えることです。

• template-only-componentを使用するとパフォーマンスが向上する可能性がありますが、trには、いくつかの内部スタイルを計算するためのバッキングクラスが必要です。 問題を示すために例を簡略化しました。
• すべてのリファクタリングを使用すると、2.18に対して2％（283ms-> 276ms）のパフォーマンス向上が得られます。 3.Xにアップグレードする既存の2.18アプリについて考えてみます。 2％のブーストを得るためだけにすべてのコンポーネントをリファクタリングすることは、絶対に実行可能ではありません。

@barisnisanci同意しました。アップグレード時にパフォーマンスが大幅に低下するのを防ぐために、この種のリファクタリングが必要であることを示唆する

介在するLTSバージョン、つまり3.4、3.8、3.12、および3.16もテストすることにより、どのEmberリリースがパフォーマンス回帰を導入したかを知ることは興味深いでしょう。

@barisnisanci Ember Twiddleとember serveは、デフォルトで開発モードで実行されます。 開発中に、パフォーマンスを大幅に低下させる可能性のある多くの追加ツールが有効になります。 開発者の人間工学に影響を与えるほど悪い場合を除いて、通常、これをリグレッションや問題とは見なしません。 したがって、最初に、両方のバージョンを本番モードで実行していることを再確認します。

私はあなたの例をダウンロードし、本番モードで2.8と3.18の両方を並べて提供しました。 私が見つけたのは、あなたが正しいように思われるということでした。平均して、2つのヘルパー操作（ここで測定されているもの）間のタイミングは、2.8よりも3.18の方が大きいようです。 これは、多くのコントロールを使用せずに仕事用のラップトップでいくつかのサンプルを取得したことに基づいているため、確実に言うのは難しいですが、目を見張ると、わずかな変更になる可能性があります。

ただし、他のより意味のあるメトリックを見ると、変化は見られません。 特にコンテンツをレンダリングするための全体的な時間を見ると、それらは一般的にほぼ同じように見えます。 たとえば、最初のペイントまでの時間はほぼ同じです。

多くの作業が多くの場所に分散していることを覚えておくことが重要です。変更を加えると、その作業は動き回っても、_全体の_メトリックには影響しません。 これが、 TracerBenchを使用してパフォーマンスの変化をチェックする理由です。これは、レンダリングの全体的なフェーズを考慮し、ヘルパーの実行間のタイミングなど、_micro_レベルではなく_macro_レベルですべての変更を考慮するように設計されているためです。

これらの結果を検証し、一般的にスリップしていないことを確認するために、TracerBenchテストをより長い期間にわたってすぐに実行する必要があります（通常、潜在的なリグレッションが予想される小さな変更に使用します）。 また、トレンドラインを確認できるように、定期的に実行するようにしてください。

@pzuraqリポジトリをrowsCount:300更新したところ、 columnsCount:20違いがより目立つようになりました。 どちらも--environment production

• 3.18最初のペイント：3489ミリ秒
  
• 2.18最初のペイント：2814ミリ秒
  

また、JSヒープは3.18でリリースされなかったが、GCで運が悪かった可能性があることにも気づいた。

カウントを増やす代わりに、スタイルバインディング、サービスインジェクション、コンポーネントのより重い計算を追加できますが、根本的な問題を隠す可能性があります。

あなたが言ったように、全体的な測定基準は小さな変更よりもはるかに重要です。 ただし、この場合、わずかな違いがパフォーマンスの大幅な低下につながります。 3.18にアップグレードした後、商用アプリケーションの初期レンダリング時間が15秒から20秒に増加しました。 わずかなミリ秒の変化ではなく、パーセンテージの観点から回帰を検討することを願っています。

当社はこの問題に苦しんでいます。 残り火バージョンを2.18から3.16に更新しました。 その後、レンダリング時間は「50」パーセントより長くなりました。 複雑な構造を使用すると、わずかなミリ秒の変化ではなく、レンダリング時間の違いがより明白になりました。 この問題に関する更新はありますか？ レンダリング時間の50％の増加を示すベンチマークがあります。 とりあえず2.18を保持することにしました。 大幅なリファクタリングが必要な場合は、フレームワークの切り替えを検討する場合があります。

@ Caglayan06プロダクションフラグを使用していることを確認できますか？ 数字がアップルトゥアップルであることを確認したいだけです！

@ Caglayan06-これが単一のものである可能性は低いです。 @barisnisanciが提供した複製は、アプリケーションプロファイルが示すものと一致しない場合があります。 アプリの一般的な問題の再現を提供できますか（または、 @ barisnisanciの上記のリポジトリの例が使用シナリオ/プロファイル出力を表していることを確認してください）？

このスレッドでの@barisnisanciの最新の投稿についてコメントはありますか？
2.18から3.16にアップグレードした後、同様のパフォーマンスの問題が発生しました。 パフォーマンスが40％低下しました。 3.12にダウングレードしましたが、その損失の20％しか節約できず、2.18ほどではありませんでした。 前に述べた方法のリファクタリングは、フレームワークの切り替えとほぼ同じくらいの時間がかかります。 この問題に対する何らかの行動を期待しますか？

最近、ember 3.16.8にアップグレードしましたが、perfテストケースはなく、パフォーマンスの明らかな問題は今のところ見つかりません。
しかし、私はパフォーマンスの問題をすぐに解決して解決することを楽しみにしています。
>>

PS：ie11で使用されるより多くのメモリとCPU。 時々それはie11クラッシュを引き起こします。

@ Caglayan06-これが単一のものである可能性は低いです。 @barisnisanciが提供した複製は、アプリケーションプロファイルが示すものと一致しない場合があります。 アプリの一般的な問題の再現を提供できますか（または、 @ barisnisanciの上記のリポジトリの例が使用シナリオ/プロファイル出力を表していることを確認してください）？

@rwjblue @barisnisanciの例は、 @ barisnisanciの言い方と同じように

@ Caglayan06プロダクションフラグを使用していることを確認できますか？ 数字がアップルトゥアップルであることを確認したいだけです！

@scottmessingerはい、本番フラグを使用しています。 @barisnisanci 'の結果と

コード構造を改善しました。 パフォーマンスは向上しましたが、それでもember2.18バージョンほど高速ではありません。 2.18でその変更を行うと、最良の結果が得られました。

コードシステムをオーバーホールして3.16コード構文と新機能を変更することはできません。 私たちのプロジェクトは巨大であるため、これは私たちにとってコストがかかりすぎます。 おそらく、すべてのプロジェクトをリファクタリングすることは、フレームワークを変更するよりもコストがかかります。 この問題に対して何らかの措置が取られますか？

この問題に対して何らかの措置が取られますか？

はい、もちろん！ プロファイルを作成し、何が起こっているのかを理解する時間を見つける必要があります。 しかし、それは本当に誰かを待つ必要はありませんが、あなたは掘り下げます😸

@rwjblue @barisnisanciの例は、 @ barisnisanciの言い方と同じように

@ Caglayan06-うーん、それは私が実際に尋ねたものではありません。 @barisnisanciの例が機能することはわかっています。それを確認し、プロファイルを作成し、パフォーマンス特性をアプリケーションと比較して、例が機能する（そして遅い）_way_がアプリケーションと一致するかどうかを

@ Caglayan06-うーん、それは私が実際に尋ねたものではありません。 @barisnisanciの例が機能することはわかっています。それを確認し、プロファイルを作成し、パフォーマンス特性をアプリケーションと比較して、例が機能する（そして遅い）_way_がアプリケーションと一致するかどうかを

私は統合@rwjblueの@barisnisanciレポ我々のアプリケーションには、それは同様の結果が得られました。 バージョンを3.16から3.12に変更すると、パフォーマンスが向上しました。
しかし、それでも2.18バージョンほど高速ではありません。

いくつかの例のアプリケーションでは：

結果として：
コード構造、合計平均レンダリング時間を改善しました。
2.18レンダリング時間：1x秒
3.16レンダリング時間：1.6x秒。
3.12レンダリング時間：1.4x秒。

3.20にはVMアップグレードがあるので、それがここで役立つかどうか疑問に思います

@NullVoxPopuliは3.20.0-beta.2FPで運がなかった：3.4秒（3.18と同じ）

3.12の方が良い結果が得られるので、自動追跡で問題が発生する可能性があると思います。 また、＃18225は、 @ Caglayan06の3.12-> 3.16ベンチマークでのアプリケーション全体のパフォーマンスの低下を考慮して関連している可能性があります。

うーん。 後方互換性のものはどれくらいのオーバーヘッドがあるのだろうか

いくつかの一般的な質問：

• 非同期オブザーバーのオプション機能フラグの値は何ですか？
• 問題のアプリはQPを使用していますか？
• 負の速度はすべてのルートに影響しますか、それとも一部にのみ影響しますか？

いくつかの一般的な質問：

• 非同期オブザーバーのオプション機能フラグの値は何ですか？
• 問題のアプリはQPを使用していますか？
• 負の速度はすべてのルートに影響しますか、それとも一部にのみ影響しますか？

@rwjblue

1. 非同期オブザーバーフラグを使用しない3.12ではデフォルトはfalseだと思います。 3.16では、両方でテストしても大きな違いはありません。
2. 主要ルートで広く使用されているQP。 ただし、パフォーマンスの低下は何も観察されませんでした。
3. すべてのルートが影響を受けます

また、サンプルリポジトリは上記のいずれも使用していませんが、3.Xではさらに低速です。 マイナーバージョンごとにレンダリング時間が徐々に長くなる可能性があるため、正確な問題を特定することはできません。

Tracerbenchのレポートによると、2.18から3.18は、このシナリオでは最大17％回帰しますが、グリマーコンポーネントへの変換が行われると、回帰ではなく最大18％向上します。

2.18から3.18その他の変更なし
2.18から3.18+オクタン+グリマーコンポーネント

このための自動ランナーを追加した独自のフォークを持っており、バージョン/コミットですばやく絞り込んでリグレッションが発生した場所を見つけることができるように、ランナーの改善に取り組んでいます。 https://github.com/runspired/version-performance/runs/801596557

これらのテストを設定してくれた@runspiredに大いに感謝します！ 回帰を確実に測定するための確実な設定ができたので、これらの問題の修正に向けて反復することができます。

コンテキストとして、 @ krisseldenはTracerBenchを、特に全体的な方法でパフォーマンスをテストするためのツールとして開発し、デコレータの自動追跡/改訂追跡など、内部の主要なリファクタリングに使用しています。 LinkedInでは、Emberをアップグレードするたびにアプリケーションをテストするために使用していますが、このレベルのリグレッションは見られません。

しかし、それは間違いなく私たちが見逃したものかもしれません。 最後に、特定のユースケースと動作を持つ特定のアプリをテストしています。 これは、テストケースアプリが@barisnisanciの複製など、回帰した機能を使用していなかったために検出できなかった問題である可能性があります。 また、その複製の問題を修正しても、他の問題を修正できない可能性もあります。そのため、リグレッションが発生している場合は、ユースケースの複製をぜひお勧めします。 TracerBenchのセットアップを使いやすくして、ローカルでテストし、 @ runspiredのような予定です。

正確な問題が何であるかを理解し、解決策を見つけるために掘り下げていきます。 最も重要なことは、このレベルのリグレッションは、Octaneでスピードアップが見られたとしても、_any_APIでは受け入れられ

今後のアップデートにご期待ください。状況がわかり次第お知らせします。

@runspiredの邪悪なクールなhttps://github.com/TracerBench/tracerbench-compare-actionに感謝し

これについて簡単な更新をしたかっただけです：

私たちは、と設定@runspired 1に類似TracerBenchテスト走っemberobserver.comいかなるがあったかどうかを確認するために私たちの通常のテストアプリケーションの一つである、カエル沸騰のバージョンから重要ではなかった（例えば、小さなパフォーマンスの変化を発生していましたバージョンですが、合計すると大きなシフトになります）。 そのテストの結果は次のとおりです。

ember-observer-2.18-3.18.pdf

これらの結果から、2つのかなり決定的なジャンプがあることがわかります。

1. Ember3.0からEmber3.1
2. Ember3.16からEmber3.17

3.17でのリグレッションは、Glimmer VMのアップグレードによるものです。これはかなり最近のものであり、LTSサイクルで間もなく更新されるアプリケーションに影響を及ぼし始める可能性があるため、現在、これを減らすことに重点を置いています。

3.1でのリグレッションは、コアチームとの話し合いの結果、当時実際に知られていました。 これは、一部、ネイティブゲッターを有効にし、 Object.definePropertyを使用したことが原因

一般に、この問題の冒頭で提起された{{each}}シナリオは、emberobserver.comよりもさまざまな方法で後退したようです。 3.17回帰を掘り下げたら、 {{each}}最適化に焦点を当てて、そこで一般的に何を改善できるかを確認します。

お待ちいただき、ありがとうございます。

この問題に関する最新情報を入手できますか？ 約2ヶ月になります。

はい！ 2か月が経ちましたが、私たちはこの問題に懸命に取り組んでおり、GlimmerVMでリファクタリングを継続しています。

前に述べたように、私たちは2つの別々の修正セットに焦点を合わせていました。

1. 次のLTSにアップグレードしようとしている人々のために、3.20LTSリリースに着陸するための低リスクリファクタリング
2. 長期的にパフォーマンスを向上させるために、マスターに着陸するための大規模なリファクタリング

最初の一連の修正では、最も影響を受けたコードであるため、かなりの量の従来のEmberコードをリファクタリングしました。 LinkedInの内部アプリケーションでのテストに基づいて、この方法で全体的なパフォーマンスの低下を3.16〜3.20から統計的に有意でない量まで減らすことができました。 残念ながら、Ember Observerに対してテストを実行する機会はありませんでしたが、通常はかなり密接に追跡しているため、同様の結果になると思います。

2番目の修正セットでは、次のような多くの修正が非常に大きかったため、比較的最近になりました。

• 内部で完全に自動追跡されるようにVMを更新し、余分なタグを取り除きます
• 非常に複雑な多くの実装ではなく、単一の単相参照クラスを使用するようにVMをリファクタリングする
• 未使用のAoTコンパイルモードの削除

結果はかなり素晴らしいです！

results.pdf

これは、Emberの現在のマスターをEmber 2.18と比較しており、上記の@barisnisanciからの複製です。 さて、前述のように、これは非常に特殊なユースケースのベンチマークであり、これも非常に単純です。 実際のアプリのベンチマークでこのような劇的な改善は見られませんでしたが、全体的にははるかに控えめでした。 うまくいけば、これが@barisnisanciや他のアプリケーションに役立つことを

残り火のマスターブランチで上記のレポをテストしました。 それでも最初のペイント：（3035.7ミリ秒）は2.18（2752.3ミリ秒）よりも大きいようです

また、さまざまな残り火バージョンを使用して本番環境でテストしました。 マスターブランチは、アプリの3.12よりも％25から％40遅いようです。 以下の結果では、大幅なリファクタリングなしでemberをアップグレードすることはできません。

@barisnisanci申し訳ありませんが、そうです！ このスレッドで前述したように、A。問題を確認し、B。全体として改善とより良い解決策に向けて反復できるようにするには、これらの結果を統計的に適切な方法で再現する必要があります。 これらのベンチマークを自分で実行できるようにTracerBenchをアプリケーションに追加するか、 master問題を示す別の複製を作成することをお勧めします。