对于此代码段，PLINQ 比实际 Linq 慢答案

【问题标题】：PLINQ slower than actual Linq for this snippet对于此代码段，PLINQ 比实际 Linq 慢
【发布时间】：2019-03-04 21:18:51
【问题描述】：

下面是代码sn-p。使用 EF6。

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

为什么 PLINQ 比较慢？

【问题讨论】：

这看起来更像是新闻而不是问题。你有什么问题？
在多线程上做事并不总是比单线程运行更快。在您开始在代码中使用并行指令之前，需要考虑很多因素。
如果表凸轮非常大，您可以考虑并行方法。然后您可以使用单独的 DbContext 或 ObjectContext 实例并使用 CancellationTokenSource，这样您就可以在找到匹配行后立即取消并行搜索并尽快返回。
This answer 可能是相关的：请注意，LINQ-To-Entities 并不真正适用于 AsParallel。通常，它会导致您的代码运行速度比顺序运行慢。
.AsParallel() 采用 IEnumerable，而不是 IQueryable，因此如果这是 Linq-To-Entities，它不仅运行速度较慢，而且会将整个表枚举到内存中（在 AsParallel 之前没有 where 子句）然后在内存中运行 Where 和 Select 枚举器。

标签： c# entity-framework entity-framework-6 task-parallel-library plinq

【解决方案1】：

如果您查看.AsParallel() 的签名，它需要一个IEnumerable<T>，而不是IQueryable<T>。 linq 查询仅在保存为 IQueryable 时转换为 SQL 语句。一旦你枚举它，它就会执行查询并返回记录。

所以要分解你的查询：

context.cam.AsParallel()

这段代码基本上会在数据库上执行SELECT * FROM cam，然后开始迭代结果。结果将被传递到ParallelQuery。这实际上会将整个表加载到内存中。

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

在此之后，所有这些操作将并行发生。与启动大量线程并管理它们之间的锁定和并发性（PLINQ 会为您处理）的开销相比，一个简单的字符串相等比较可能非常便宜。并行处理和成本/收益是一个复杂的话题，但通常是best saved for CPU-intensive work。

如果您跳过了 AsParallel() 调用，则在 linq 语句中，所有内容始终保持为 IQueryable，因此 EntityFramework 将发送一个类似于 SELECT fg FROM cam WHERE cams = 'edsfdf' 的 SQL 命令并返回该单个结果，SQL Server 将优化到非常快速的查找，尤其是在凸轮上有索引的情况下。

【讨论】：

解释很清楚。如果 PLINQ 具有相关的复杂性，那么它存在的真正好处是什么？
另外，如果您可以分享详细说明其理想用法的案例研究，将会很有帮助。谢谢！
docs.microsoft.com/en-us/dotnet/standard/parallel-programming/… 提供了一些关于 PLINQ 何时最有用的好信息。

【解决方案2】：

速度较慢，因为您在不好的地方使用了 parralisim。您的 Where 子句不做繁重的工作，那么使用 PLINQ 不是一个好场景。

如果 PLINQ 带有相关的复杂性那么它存在的真正好处是什么？

您不需要一百个人来寻找家中失踪的孩子，因为寻找 100 个人比自己寻找孩子需要更长的时间。但是如果你要搜索一片森林，这个开销是值得的，因为光是在大森林里找到一个孩子就比在一个大森林里找到 100 个人要花更长的时间！

在正确的时间和正确的地方使用并行是有效的。

【讨论】：