百万と1日INotifyPropertyChanged

ユーザーインターフェイスの最適化は専用です。



画像

ユーザーインターフェイスは、高速、非常に高速、非常に高速でなければなりません。


ナノ秒を節約しようとすると、多くの場合、秒を節約できる場所が見落とされます。 おもしろいことに、小さなリストを2秒間描いたときのinりに、「ダフフェフには何もできない」という真剣な答えが返ってきました。 INotifyPropertyChanged habrahabr.ru/post/281294の可能な実装をすべて検討すると、ユーザーインターフェイスとこのインターフェイスに関与する開発者のパフォーマンスの理想的なバランスについて疑問が生じます。 特定の実装の選択がインターフェースの動作にどのように影響するかを理解したかったのです。



アスリート:



  1. 画像 OnPropertyChanged(文字列)-渡されたプロパティ名を持つ古典的な呼び出し
  2. 画像 OnPropertyChanged(nameof)は前のものと同じですが、...
  3. 画像 OnPropertyChanged([CallerMemberName])-自動プロパティ名決定
  4. 画像 OnPropertyChanged(()=> Expression)-プロパティを持つ式を渡す
  5. 画像 SetProperty <T>(ref storage、T値、[CallerMemberName])-ハイブリッド
  6. 画像 ObservableObject <T>-これはastudentから通知された
  7. 画像 AOP-Unityによって生成されたプロキシ、過去のトピックからの実装




(カタツムリの色付けは、フロントエンドでのグルーミングの最も興味深い、有害な効果です)

実行はバッグ内で行われます。これは、各参加者がPropertyChanged(空の静的メソッド)にサブスクライブし、この段階で参加者6に特別な注意が払われているためです。 インターフェイスをまだ構成できる場合は、DependencyPropertyDescriptorを介してサブスクライブする必要があります。彼は自慢することにしました。 追跡-参加者ごとに1,000万サイクル。



はじめに! 注意! 行け!



事は速くありません、あなたは待たなければなりません。

...

...

画像

実験は数回行われ、結果はほぼ同じです。

10,000,000 1.文字列 2. nameof 3. CallerMemberName 4.表現 5. SetProperty 6. ObservableObject 7. AOP
0.129 0.13 0.121 9,016 0.372 4,248 22,643




受賞。



そもそも、カタツムリ1、2、3を入手するのは当然です!

2番目のカタツムリ5はあまり届きませんでした

ブロンズは当然、非標準ソリューションNo. 6になります

次は式です

そして、スポーツのカタツムリの達人はこのすべてを閉じます;反射は彼を台無しにしました。



まとめます。



明らかに、最高速度を達成するには、1,2,3ファミリーのツールを使用する必要があります。 aopを使用すると、アプリケーションの速度が完全に低下します。もちろん、最適でないソリューションが使用されたため、デリゲートを作成して3秒節約することで反射を最適化できますが、全体像は変わりません。

そして今、実際に! いずれかの実装を使用しても、パフォーマンスに影響はありません。 1,000万件の呼び出しには25秒かかります。つまり、1秒あたり40万件の呼び出しが必要です。 400k 、突然これが発生した場合、VMは悲しみと後悔なく、酸に溶解する必要があります。



このような場合にPSをナノ秒単位で節約することは無意味です。原則として、パフォーマンスの問題の大部分はテクノロジだけでなく、不正な使用にもかなりの割合を占めています。



次は言葉なしで...
画像




All Articles