PLinqがより高価であることがわかった場合、PLinqは自動的に非並列Linqを使用することを読みました。そこで、(可能な場合) すべてに PLinq を使用して、ランタイムにどれを使用するかを決定させない理由を考えました。
アプリはマルチコア サーバーにデプロイされ、並列処理を処理するためのコードをもう少し開発しても問題ありません。
plinq をデフォルトとして使用することの落とし穴は何ですか?
PLinqがより高価であることがわかった場合、PLinqは自動的に非並列Linqを使用することを読みました。そこで、(可能な場合) すべてに PLinq を使用して、ランタイムにどれを使用するかを決定させない理由を考えました。
アプリはマルチコア サーバーにデプロイされ、並列処理を処理するためのコードをもう少し開発しても問題ありません。
plinq をデフォルトとして使用することの落とし穴は何ですか?
落とし穴の1つは、セットでの注文を活用する能力を失うことです。
次のコードを取ります。
var results = new int { 0 ,1 ,2 ,3 };
var doSomethingSpecial = (from r in results.AsParallel() select r / 2).ToArray();
結果が順番に来ることを期待することはできないので、結果 はセットの任意の順列である可能性があります。これは最大の落とし穴の1つであり、順序付けられたデータを処理している場合、並べ替えのコストが原因でパフォーマンス上の利点が失われる可能性があります。
もう1つの問題は、既知の例外をキャッチする機能が失われることです。そのため、nullポインター例外をキャッチすることも(これを実行する必要があるとは言わないで)、FormatExceptionをキャッチすることもできませんでした。
すべての場合に常にPlinqを使用する必要がない理由はたくさんありますが、もう1つだけ強調します。「非並列Linqの自動使用」についてはあまり読みすぎないでください。クエリが単純であるか、複雑すぎて並列で実行できない場合にのみ処理できます。
PLINQを使用すればするほど、サーバーで消費するリソースが増え、実行中の他のスレッドからリソースが奪われることを常に念頭に置いてください。
資力: