PLINQ медленнее, чем фактический Linq для этого фрагмента - PullRequest
Новая
       51

PLINQ медленнее, чем фактический Linq для этого фрагмента

0 голосов
/ 29 сентября 2018

Ниже приведен фрагмент кода.Используется EF6. 

var itemNames = context.cam.AsParallel()
                    .Where(x=> x.cams == 
                     "edsfdf")
                    .Select(item => item.fg)
                    .FirstOrDefault();

Почему PLINQ медленнее?

1 Ответ

0 голосов
/ 29 сентября 2018

Если вы посмотрите на подпись .AsParallel(), она займет IEnumerable<T>, а не IQueryable<T>.Запрос linq преобразуется только в оператор SQL, пока он сохраняется как IQueryable.Как только вы перечислите его, он выполнит запрос и вернет записи.

Итак, чтобы разбить ваш запрос: 

context.cam.AsParallel()

Этот бит кода, по сути, будет выполнять SELECT * FROM cam вбазы данных, а затем начать итерацию по результатам. Результаты будут переданы в ParallelQuery .По существу, это приведет к загрузке всей таблицы в память. 

.Where(x=> x.cams == "edsfdf")
.Select(item => item.fg)
.FirstOrDefault()

После этого все эти операции будут выполняться параллельно.Простое сравнение равенства строк, вероятно, очень недорогое по сравнению с издержками, связанными с вращением большого количества потоков и управлением блокировками и параллелизмом между ними (о которых PLINQ позаботится за вас).Параллельная обработка и затраты / выгоды - сложная тема, но обычно лучше всего сохранять для работы, интенсивно использующей процессор .

Если вы пропустили вызов AsParallel(), все останется как IQueryable allпуть через оператор linq, поэтому EntityFramework отправит одну команду SQL, которая выглядит примерно как SELECT fg FROM cam WHERE cams = 'edsfdf', и выдаст этот единственный результат, который SQL Server оптимизирует для очень быстрого поиска, особенно если есть индекс для кулачков.

...