PLINQ自动并行化本地LINQ查询。 PLINQ具有易于使用的优点，因为它可以减轻工作分区和结果整理到框架的负担。
在一般编程中，我应该使用简单的LINQ或PLINQ吗？
对于太大的数据，PLINQ对用户更好吗？或者对小数据更好？
答案 0 :(得分：6)
鉴于AsParallel透明地并行化LINQ查询，问题出现了，“为什么Microsoft不能简单地并行化标准查询运算符并使PLINQ成为默认值？”
选择加入方法有很多原因。首先，要使PLINQ有用，必须有合理数量的计算密集型工作才能将其转移到工作线程。大多数LINQ to Objects查询执行速度非常快，不仅不需要并行化，而且分区，整理和协调额外线程的开销实际上可能会减慢速度。
此外：
关于元素排序，PLINQ查询的输出（默认情况下）可能与LINQ查询不同。
以下查询运算符会阻止查询并行化，除非源元素位于其原始索引位置：
Take，TakeWhile，Skip和SkipWhile Select，SelectMany和ElementAt的索引版本 大多数查询运算符都会更改元素的索引位置（包括删除元素的元素，例如Where）。这意味着如果你想使用前面的运算符，它们通常需要在查询的开头。
以下查询运算符是可并行化的，但使用昂贵的分区策略，有时可能比顺序处理慢：
加入，GroupBy，GroupJoin，Distinct，Union，Intersect和Except Aggregate运算符的标准化身中的种子重载是不可并行化的 - PLINQ提供了特殊的重载来处理这个问题。
何时使用PLINQ
很有可能在现有应用程序中搜索LINQ查询并尝试并行化它们。这通常是非生产性的，因为LINQ显然是最佳解决方案的大多数问题往往执行得非常快，因此不能从并行化中受益。更好的方法是找到CPU密集型瓶颈，然后考虑“这可以表示为LINQ查询吗？”（这种重组的一个受欢迎的副作用是LINQ通常使代码更小，更易读。）
PLINQ非常适合令人尴尬的并行问题。它也适用于结构化阻塞任务，例如一次调用多个Web服务（请参阅调用阻塞或I / O密集型函数）。
PLINQ可能是成像的不良选择，因为将数百万像素整理成输出序列会产生瓶颈。相反，最好将像素直接写入数组或非托管内存块，并使用Parallel类或任务并行来管理多线程。 （但是，有可能使用ForAll来击败结果排序。如果图像处理算法自然适用于LINQ，那么这样做是有意义的。）