我什么时候应该在 linq/plinq 中使用 AsParallel()
我正在寻找通过使用 plinq 来利用 linq 中并行编程的优势，我不确定我是否完全理解其用途，除了它会更有效地利用所有 cpu 核心这一事实，因此对于大型查询来说，它可能会更快。我可以简单地在 linq 调用上调用 AsParallel() 来利用 eplinq 功能吗？它总是会更快吗？或者我应该只在有大量数据需要查询或处理时才使用它？
I'm looking make use of the advantages of parallel programming in linq by using plinq, im not sure I understand the use entirely apart from the fact its going to make use of all cpu cores more efficiently so for a large query it might be quicker. Can I just simply call AsParallel() on linq calls to make use of th eplinq functionality and it will always be quicker? Or should I only use it when there is a lot of data to query or process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能仅仅假设并行执行总是更快。这取决于。在某些情况下，通过并行执行操作，您将在多核处理器上获益匪浅。在其他情况下，您只会减慢速度，因为并行循环比简单循环有轻微的过热。
例如，请参阅我的其他答案解释了为什么嵌入式并行循环可能是一场灾难。
现在，要知道在精确的上下文中使用并行循环是否是一个好主意，最好的方法是测试并行和非并行实现并测量它们所花费的时间。
You can't just assume that execution in parallel is always faster. It depends. In some situations you will gain a lot on multi-core processors by doing things in parallel. In other cases, you will just slow the things down, since parallel loops have a small overheat over simple loops.
For example, see my other answer which explains why embedded parallel loops can be a disaster.
Now, the best way to know if it is a good idea to use parallel loop in a precise context is to test both parallel and not parallel implementations and to measure the time they take.
为了进一步补充答案，这还取决于您的数据。稍微“老派”一下，您可以沿着循环展开的道路，使用 for 代替 foreach 等等。
然而，您确实需要确保您没有进行微观优化。根据您的数据获取和数据大小（当然是分页数据），您可能可以不使用它。
这并不是说让您的 linq 多核感知不酷。但请注意执行此类操作的设置成本，以便能够权衡维护和调试代码的复杂性带来的好处。
如果您的算法已经是一流的，那么看看 plinq 扩展、映射缩减机制或类似的可能是可行的方法。但首先要检查你的算法和你的整体收益。以正确的方式操作正确的集合（等等）总是会带来好处（和问题！）。
你想解决什么问题？
To further add to the answer, it also depends on your data. Going a little 'old school' for a moment you could go down the road of loop unrolling, using for instead of foreach and so on and so forth.
However, you really need to ensure you aren't micro-optimising. Depending on your data fetches and the size of data (certainly with paged data) then you can probably get away with not using it.
That's not to say that making your linq mult-core aware isn't cool. But be aware of the setup costs of doing something like that and so be able to weigh up the benefits against the complexities of maintaining and debugging that code.
If your algorithm is already top notch then looking at the plinq extensions, a map reduce mechanism or similar may be the way to go. But first check your algorithm and your overall benefits. Operating on the right kind of collection (etc) in the right kind of way will always bring its own benefits (and problems!).
What are you trying to solve?