我應該使用哪一個：LINQ或PLINQ

PLINQ自動並行化本地LINQ查詢。 PLINQ具有易於使用的優點，因爲它將工作分區和結果歸類的負擔減輕到框架。我應該使用哪一個：LINQ或PLINQ

在一般的編程中，我應該使用簡單的LINQ或PLINQ嗎？

PLINQ對用戶來說是否更適合太大的數據？或者對於小數據也更好？

2013-06-19 Waheed

我想也許你發現這個線程，但如果不是，我會推薦你閱讀答案http://stackoverflow.com/ a/8547903/896258 – meorfi

我會推薦這個鏈接。（這是一個非常簡短的例子）。它不取決於你有多大的數據，而是需要多少時間才能解決主要的LINQ請求。 http://www.codeproject.com/Tips/374420/When-to-use-PLINQ-vs-LINQ – meorfi

由於進行AsParallel透明並行化LINQ查詢，出現這樣的問題，「你爲什麼不只是微軟並行標準查詢操作符，使PLINQ默認？」

有對選入多種原因做法。首先，爲了使PLINQ有用，必須進行合理數量的計算密集型工作，以便將其用於工作線程。大多數LINQ to Objects查詢的執行速度非常快，不僅平行化不必要，而且分區，整理和協調額外線程的開銷實際上可能會減慢速度。

此外：

一個PLINQ查詢（默認情況下）的輸出可以從LINQ查詢不同相對於元件排序。

下面的查詢操作阻止並行查詢，除非源元素是在原來的標定位置：

走，TakeWhile，跳過和SkipWhile 選擇，的SelectMany和ElementAt的的索引版本大多數查詢運算符都會更改元素的索引位置（包括那些刪除元素的位置，如Where）。這意味着如果你想使用前面的操作符，他們通常需要在查詢的開始。

下面的查詢操作是並行的，但使用昂貴的分區策略，有時可以比順序處理慢：

加入，的GroupBy，羣組加入，層次分明，聯盟，交叉，除了的總運營商的種子重載在他們的標準化身中是不可並行化的--PLINQ提供了特殊的重載來處理這個問題。

當使用PLINQ

人們很容易與他們並行搜索LINQ查詢和實驗現有應用程序。這通常是徒勞的，因爲LINQ顯然是最好的解決方案的大多數問題傾向於執行得非常快，所以不會從並行化中受益。一個更好的方法是找到一個CPU密集型瓶頸，然後考慮「這可以表示爲LINQ查詢嗎？」（這種重組的一個受歡迎的副作用是LINQ通常會使代碼更小且更具可讀性。）

PLINQ非常適合於令人尷尬的並行問題。它也適用於結構化阻塞任務，例如一次調用多個Web服務（請參閱調用阻塞或I/O密集函數）。

PLINQ對於成像來說可能是一個糟糕的選擇，因爲將數百萬像素整理成輸出序列會造成瓶頸。相反，最好將像素直接寫入數組或非託管內存塊，並使用並行類或任務並行性來管理多線程。（但是，可以使用ForAll來打敗結果整理。這樣做是有道理的，如果圖像處理算法自然適合LINQ。）

來源

2013-06-19 06:21:42 Waheed

這是複製從： http://www.albahari.com/threading/part5.aspx#_PLINQ_Limitations 由Waheed提供的很好的老食譜，不是一個，他在這裏做了同樣的事情： http://stackoverflow.com/questions/8540646/difference-linq-and-plinq – user603563

我應該使用哪一個：LINQ或PLINQ

回答

相關問題