Given that AsParallel transparently parallelizes LINQ queries, the question arises: "Why didn’t Microsoft just parallelize standard query operators and make PLINQ the default?"
There are a number of reasons for denying access. First, for PLINQ to be useful, there must be a reasonable amount of computationally intensive work for it to work with workflows. Most LINQ to Objects queries run very quickly, and not only are there no need for parallelization, but the overhead of partitioning, sorting, and coordinating additional threads can actually slow things down.
Additionally:
The result of the PLINQ query (default) may differ from the LINQ query regarding the ordering of the elements.
The following query operators do not allow parallelization of the query if the source elements are not in the initial indexing position:
Take, TakeWhile, Skip, and SkipWhile Indexed versions of Select, SelectMany, and ElementAt Most query operators change the position of indexing elements (including those that delete elements, such as Where). This means that if you want to use the previous operators, they usually should be at the beginning of the request.
The following query operators are parallelizable, but use an expensive splitting strategy, which can sometimes be slower than sequential processing:
Join, GroupBy, GroupJoin, Distinct, Union, Intersect and Except Segregation operators filled with aggregates in their standard incarnations are not parallelizable - PLINQ provides special overloads to solve this problem.
When to use PLINQ
It is tempting to look for your existing LINQ query applications and experiment with parallelizing them. This is usually unproductive, because most of the problems for which LINQ is obviously the best solution, as a rule, are performed very quickly and therefore cannot be used for parallelization. The best approach is to find a bottleneck with heavy CPU usage, and then think: “Can this be expressed as a LINQ query?” (Another side effect of this restructuring is that LINQ usually makes the code more compact and readable.)
PLINQ is well suited for embarrassing parallel issues. It also works well for structured blocking tasks, such as calling multiple web services at the same time (see Call Blocking or I / O Functions).
PLINQ may not be a good choice for image processing, as collecting millions of pixels in the output sequence creates a bottleneck. Instead, it is better to write pixels directly to an array or unmanaged memory block and use the Parallel class or parallelism task to control a multi-threaded process. (It is possible, however, to defeat the comparison of results using ForAll. This makes sense if the image processing algorithm naturally lends itself to LINQ.)