并行何时会提高性能

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

并行版本花费的时间是常规版本的两倍。 （是的，我测试了更多的一个核心......）

I saw this https://stackoverflow.com/a/4172729/601179回答说数据切片并不总是并行对性能有好处。
同样，这一警告在并行示例的每一页中都重复出现MSDN http://msdn.microsoft.com/en-us/library/dd460719.aspx教程：

这些示例主要旨在演示用法，并且可能或 可能不会比等效的顺序 LINQ to Objects 运行得更快 查询

我需要一些规则和技巧，什么时候并行会提高我的代码的性能，什么时候不会。
明显的答案是“测试您的代码，如果并行循环更快，则使用它”，这是绝对正确的，但我猜没有人对他编写的每个循环进行性能分析。

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

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

• 如果工作本质上是可并行的，那么并行化真的能节省时间吗？你可以煮一锅意大利面，里面有一百个面条，也可以煮二十锅意大利面，每个意大利面有五个面条，最后把结果倒在一起。我向你保证，并行烹饪意大利面的任务不会让你更快地吃晚饭。

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

当工作完成时，并行化往往是一个胜利enormous and 可并行化。将十万个指针设置为空是计算机可以在极短的时间内完成的事情；没有巨大的成本，所以没有节省。尝试做一些不平凡的事情；比如说，编写一个编译器并并行对方法体进行语义分析。你在那里获胜的可能性更大。