LINQ vs PLINQ: когда преимущества накладных расходов перевешивают?

Question

Я работаю над проектами в основном типа электронной коммерции.наш архитектор получил от клиента инструкции использовать PLINQ, так как он гораздо выгоднее, чем LINQ, поскольку он работает параллельно и использует все ядра процессоров, что приводит к быстрым ответам.Клиент может предложить PLINQ + Repository, если это возможно.

Так что я просто хочу знать, какой из них следует использовать в небольших и средних приложениях.Возможно ли использовать Plinq + Repository.В соответствии с моими выводами, я обнаружил, что Plinq имеет больше накладных расходов, чем linq, если мы не обрабатываем вещи должным образом.Пожалуйста, помогите мне.

Answer 1

Невозможно ответить на этот вопрос, не зная гораздо более подробную информацию о вашем приложении. У PLINQ есть накладные расходы, чтобы распределить рабочую нагрузку по рабочим потокам, а затем координировать работу между ними. Если вы обрабатываете сотни тысяч объектов и имеете значительный объем работы для каждого из них, то да, это может принести пользу. В конце концов, единственный способ действительно узнать, принесет ли PLINQ пользу вам, - это создать профиль с использованием реалистичного набора данных.

Answer 2

Если цикл for имеет небольшое тело, он может работать медленнее, чем эквивалентный последовательный цикл. Более низкая производительность вызвана накладными расходами, связанными с разделением данных, и стоимостью вызова делегата на каждой итерации цикла. Для решения таких сценариев класс Partitioner предоставляет метод Partitioner.Create, который позволяет обеспечить последовательный цикл для тела делегата, так что делегат вызывается только один раз для раздела, а не один раз для итерации.

См. здесь .

Это относится к PLINQ.

См. здесь для PLINQ.

Answer 3

LOL.

Тот, кто платит пайперу, называет мелодию

Как правило, это инженерная проблема.Поговорите с архитекторами и клиентами и выясните, какие метрики они будут использовать для измерения эффективности результатов.

Затем, используя эти метрики, найдите оптимальное решение Linq, PLinq или другое, а затем сообщите свои результаты.

В основном все технологии хороши, и размер приложения измеряется разными способами.Так что ваш термин «маленький» не имеет смысла.