LINQ 与 PLINQ：何时开销超过收益？
我正在从事基本上电子商务类型的项目。我们的架构师已收到客户的指示，要求使用 PLINQ，因为它比 LINQ 更有利，因为它们并行工作并使用处理器的所有核心，从而实现快速响应。如果可能的话，客户建议是 PLINQ + Repository。
所以我只想知道，中小app中，关注哪一款好。使用Plinq + Repository是否可行。根据我的发现，如果我们没有正确处理这些内容，我发现 Plinq 的开销比 linq 更多。请帮我。
I am working on projects basically ecommerce type. our architect has got instructions from client to use PLINQ as its much more beneficial than LINQ, as they works in parallel and uses all cores of the processors, resulting in quick responses. Client suggestion is PLINQ + Repository if possible.
So I just want to know, which one is good to follow in small and medium app. Is it feasible to use Plinq + Repository. As per my findings, I found Plinq has more overhead than linq if we are not handling the stuffs properly. Please help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果不了解有关您的应用程序的更多详细信息，就不可能回答这个问题。 PLINQ 需要将工作负载分散到工作线程，然后协调它们之间的工作。如果您正在处理数十万个实体，并且每个实体都有大量有意义的工作要做，那么它确实可以受益。最后，真正了解 PLINQ 是否对您有利的唯一方法是使用实际数据集进行分析。
It is impossible to answer this question without knowing far more details about your application. PLINQ has overhead to fan out the workload to worker threads and then coordinate the work amongst them. If you are processing hundreds of thousands of entities and have a meaningful amount of work to do for each one, then yes it can benefit. In the end, the only way to really know if PLINQ will benefit you is to profile using a realistic data set.
当
for循环体较小时，它的执行速度可能比等效的顺序循环慢。性能降低是由数据分区所涉及的开销以及每次循环迭代调用委托的成本造成的。为了解决这种情况，Partitioner类提供了Partitioner.Create方法，该方法使您能够为委托主体提供顺序循环，以便仅调用委托一次每个分区，而不是每次迭代一次。请参阅此处。
这适用于 PLINQ。
有关 PLINQ，请参阅此处。
When a
forloop has a small body, it might perform more slowly than the equivalent sequential loop. Slower performance is caused by the overhead involved in partitioning the data and the cost of invoking a delegate on each loop iteration. To address such scenarios, thePartitionerclass provides thePartitioner.Createmethod, which enables you to provide a sequential loop for the delegate body, so that the delegate is invoked only once per partition, instead of once per iteration.See here.
This applies to PLINQ.
See here for PLINQ.
哈哈。
一般来说，这是一个工程问题。与架构师和客户交谈，确定他们将使用哪些指标来衡量可交付成果的性能。
然后使用这些指标找到 Linq、PLinq 或其他的最佳解决方案，然后报告您的发现。
总的来说，所有技术都有好处，并且应用程序的大小以不同的方式衡量。所以你说的‘小’是没有意义的。
LOL.
Generally though, this is an engineering issue. Talk to the architects and clients and work out what what metrics they will be using to measure the performance of the deliverables.
Then using these metrics find the optimal solution Linq, PLinq or other and then report back your findings.
In the main all technologies are good for something and the size of the app is measured in different ways. So your term 'small' is meaningless.