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