c# - 什么时候并行提高性能

Question

我试图了解何时使用 parallel将提高性能。
我用一个简单的代码对其进行了测试，该代码在 List<Person> 中运行了超过 100,000 个项目。并将每个名称更改为 string.Empty .

并行版本花费的时间是普通版本的两倍。 (是的，我测试了更多的一个核心......)

我看到了this回答说不总是并行的数据片段对性能有好处。
在 MSDN 中平行示例的每一页中也重复了这一警告。教程:

These examples are primarily intended to demonstrate usage, and may or may not run faster than the equivalent sequential LINQ to Objects queries

我需要一些规则和提示，何时并行会提高我的代码的性能，何时不会。
显而易见的答案是“测试你的代码，如果并行循环更快，就使用它”，这是绝对正确的，但我想没有人对他编写的每个循环都运行性能分析。

Answer 1

想想什么时候值得在现实生活中并行化某些东西。什么时候坐下来自己从头到尾完成一项工作比较好，什么时候雇用二十个人比较好？

• 工作本质上是可并行的还是本质上是串行的？有些工作根本无法并行:九个女人不可能在一个月内一起工作生一个 child 。有些工作可以并行进行，但结果很糟糕:你可以雇用二十个人，给他们每人分配五十页《 war 与和平》给你读，然后让他们每人写一篇文章的二十分之一，将所有文章片段粘在一起，然后提交论文；那不太可能取得好成绩。有些工作非常可并行:二十个人拿铲子挖洞的速度比一个人快得多。

• 如果工作本质上是可并行化的，并行化真的能节省时间吗？你可以煮一锅意大利面加一百条面条，也可以煮二十锅意大利面加五根面条，最后倒在一起。我向您保证，并行处理意大利面的任务不会让您更快地吃晚餐。

• 如果工作本质上是可并行的，并且有可能节省时间，那么雇用这些人的成本是否可以及时节省时间？如果自己完成工作比雇人更快，那么并行化就不是胜利。雇用 20 个人来完成一件需要你五秒钟的工作，如果你需要一天才能找到这些人，那么希望他们能在四分之一秒内完成这件事并不能节省成本。

当工作庞大 并且可并行化 时，并行化往往会取得胜利。将十万个指针设置为 null 是计算机可以在几分之一秒内完成的事情；没有巨大的成本，所以没有储蓄。尝试做一些不平凡的事情；比如说，编写一个编译器并并行地对方法体进行语义分析。您将更有可能在那里获胜。