Я читал, что PLinq будет автоматически использовать непараллельный Linq, если он найдет PLinq более дорогостоящим. Поэтому я подумал, почему бы не использовать PLinq для всего (когда это возможно) и позволить runtime решить, какой из них использовать.
Приложения будут развернуты на многоядерных серверах, и я готов разработать немного больше кода для работы с parallelism.
Каковы подводные камни использования plinq по умолчанию?
Одно падение ямы - вы теряете способность использовать порядок в наборах.
Возьмите следующий код:
var results = new int { 0 ,1 ,2 ,3 };
var doSomethingSpecial = (from r in results.AsParallel() select r / 2).ToArray();
Вы не можете рассчитывать на результаты, поступающие в порядок, поэтому результатом могут быть любые перестановки набора. Это одна из самых больших ошибок, в том смысле, что если вы имеете дело с упорядоченными данными, тогда вы можете потерять преимущества производительности из-за стоимости сортировки.
Другая проблема заключается в том, что вы теряете способность обнаруживать известные исключения. Таким образом, я не мог поймать исключение нулевого указателя (не говоря, что вы должны это делать) или даже поймать исключение FormatException.
Есть масса причин, почему вы не всегда должны использовать Plinq во всех случаях, и я выделил еще один. Не читайте также "автоматическое использование не параллельного Linq", он может обрабатывать только барьерные случаи, когда запрос является простым, или будет слишком сложным для параллельной работы.
Всегда помните, что чем больше PLINQ использует больше ресурсов, которые вы будете потреблять на сервере, которые убираются из других работающих потоков.
Ресурсы