(デスクトップアプリケーションの)約200.000個のオブジェクトを処理する必要があり、各オブジェクトは処理に約20ミリ秒かかります。これをスピードアップするために、私は同時にそれをしたい。タスク並列ライブラリを使用したスケジューリング
テストのために、私は各オブジェクトを別々のタスクに入れましたが、ジョブのサイズが小さいため、わずかな速度向上しか得られません。だから私の最初の質問は:
これらのオブジェクトの最適なバッチサイズを見つけるための巧妙な(しかしあまりにも複雑ではない)方法がありますか?私は、10,20,100のオブジェクトのバッチでそれらをグループ化するのが最速かどうかについていくつかのローカルテストをすることができたと思いますが、これは少し下位のようです。
2番目(さらに重要):ほとんどのオブジェクトは、CPU時間があるたびに処理する必要があります。しかし、ユーザーは常に10-20個のオブジェクトを見ています。スムーズなユーザーエクスペリエンスを提供するために、キューの前面に常にユーザーが探しているオブジェクトを配置できるようにしたいと考えています。ユーザーは常時ナビゲートしているので、いつも注文をすばやくスケジュールできることが重要だと感じています。 (20 ms * 20は約0.4秒で処理できるはずです)。
これらのオブジェクトを処理するために良いデザインパターンを手伝ってくれる人はいますか?
処理はどのようなことをいっているのですかCPUにバインドされていますか? – svick
_optimal_ wrtバッチサイズを定義する必要があります。最も簡単には、コア/プロセッサの数で項目数を割ります。総スループットは明白な要因ですが、重要なのはユーザーにとっての応答性です。バッチサイズが大きすぎると、ユーザーがバッチ内にあるアイテムを表示したい場合、関連スレッドはそれらのアイテムを配信するには時間がかかりすぎる可能性があります(スレッドが処理されたアイテムを小グループで配信しない限り)。あなたのスレッドは、必要に応じて、アイテムX..Yがキューの先頭に移動しなければならないように、再スケジューリングをサポートすることができます。 – groverboy
'Queue'は明白なコレクションクラスですが、(SkipWhileのような拡張メソッドを使わない限り)再スケジューリングはサポートしていません。あるいは、 'AddRange'、' RemoveRange'メソッドを持つ 'List 'を使用してください。 –
groverboy