Va bene provare a utilizzare Plinq in tutte le query di Linq?

Question

Ho letto che PLinq utilizzerà automaticamente Linq non parallelo se trova che PLinq sia più costoso. Quindi ho capito perché non usare PLinq per tutto (quando possibile) e lasciare che il runtime decida quale usare.

Le app saranno distribuite su server multicore e sto bene a sviluppare un po 'più di codice per gestire il parallelismo.

Quali sono le insidie ​​nell'usare plinq come impostazione predefinita?

Answer 1

Una caduta in fossa si perde la capacità di sfruttare l'ordine nei set.

Prendere il seguente codice:

var results = new int { 0 ,1 ,2 ,3 }; 
var doSomethingSpecial = (from r in results.AsParallel() select r/2).ToArray(); 

Non si può contare sui risultati arrivando al fine per cui il risultato potrebbe essere qualsiasi permutazioni del set. Questa è una delle più grandi insidie, nel senso che se si hanno a che fare con dati ordinati, si potrebbero perdere i benefici in termini di prestazioni dovuti al costo dell'ordinamento.

Un altro problema è che si perde la possibilità di rilevare le eccezioni note. Quindi non ho potuto rilevare un'eccezione del puntatore nullo (non dicendo che dovresti mai farlo) o persino prendere un FormatException.

Ci sono un sacco di ragioni perché non si dovrebbe sempre usare Plinq in tutti i casi, e ne evidenzierò solo uno in più. Non leggere troppo in "uso automatico di Linq non parallelo", può gestire solo i casi di barriera in cui la query è semplice o sarebbe troppo complessa per essere eseguita in parallelo.

Ricorda sempre che più usi PLINQ più risorse consumerai sul server, che stanno prendendo il via da altri thread in esecuzione.

Risorse:

MSDN PLNQ white paper

Paul Kimmel on PLINQ