一般的に、品質と提案された機能は私に合っていたので、私は積極的にこれらのコンポーネントで雇用主に雇用主を植えました。
また、サーバー上にある大きなコレクションをクライアントに表示する必要があるときにいつも使用していた「銀の弾丸」が1つありました。 ItemsSourceとしてのRadGridViewとVirtualQueryableCollectionViewの束でした。 そこのアルゴリズムは非常に単純です。 ユーザーがグリッドをスクロールし、グリッドが要素の背後に登り、VirtualQueryableCollectionViewが要素を必要とするイベントを発生させ、バックグラウンドでサーバーから必要なページを読み込みます。 すべてが良好であり、この手法は長年にわたって機能しました。
しかし、暗号通貨交換プロジェクトは最近請求されました。 為替ユーザーによる主な評価基準には、為替レートと流動性があります。 ユーザーの期待に応えるために、APIによって注文を生成するボットがロードされました。 なぜなら 暗号通貨の為替レートのボラティリティは高く、注文をキャンセルして新しい注文を出す必要がありました。
そして、かつて、ExchangeバックオフィスソフトウェアはOutOfMemoryExceptionで落ち始めました。 プロファイラーは次のことを示しました。
数千の新しいSystem.Object []オブジェクト。 同時に、私のコードには何も起こりませんでした。サーバーへの新しいリクエストはありませんでした。そのような迅速なメモリ貪食の疑いはありませんでした。
同僚に症状を説明したときに啓発が来ました。 意味は次のとおりです。 ページがVirtualQueryableCollectionViewコレクションに読み込まれると、サーバー上のリストアイテムの総数を通知します。 また、内部のVirtualQueryableCollectionViewは、要素の数は等しいがダミーで満たされたリストを保持します。 System.Object []だけだと思います。 そのため、サーバー上の要素の数が数千万に達したとき（ボットのおかげ）、このリストはそれに耐えられませんでした。 はい、プロセスをx64に転送した場合、それほど速くあきらめませんが、動作することも不可能です。 このリストのサイズ変更には、ほぼ1分かかります。
リストの仮想化と特効薬に関するおとぎ話です。
PSインターフェース上のユーザーがそのようなボリュームのコレクションを表示する必要がないことを理解しています。 テキストの意味は、同僚と経験を共有することであり、おそらく将来、誰かの時間を節約することです。