Parallel.ForEach 挂起一个大循环

Question

我有一个使用 TPL 并行化的 for 循环实现。我正在使用具有 4GB RAM 和 i3 Core 处理器的戴尔笔记本电脑。我有多个parallel.foreach 使用Parallel.invoke 调用。该程序是 Enterprise Architect 的插件，用于在 EA 中创建模型图和对象。

代码是这样的：

Parallel.invoke(()=>parent1Creation(),()=>parent2Creation(),...);

每个父创建都是Parallel.foreach:

Parallel.foreach(parents, (parent) => {
    //create parent 
    //create children
    for(child in parent.children) {
        childecreation();
    }

    for(child2 in parent.children) {
        childecreation();
    }
    //can be any type and number of children
} 

我有一个问题，当我的循环大小增加时，即大约 1500-2000 次迭代，Enterprise Architect 停止工作。

这是因为我的笔记本电脑配置或我使用并行循环的方式或与企业架构师一起出现的问题吗？

我该如何解决。

Answer 1

我不建议采用这种策略。一次运行大量 Parallel.ForEach 循环不一定有助于提高性能（请参阅帖子后面的警告），尤其是当每个 Parallel.ForEach 循环都处理大量迭代时。在某些时候，使用额外的线程不会再有利于您的性能，只会增加开销。

这里需要注意的是，Parallel.ForEach 在为特定的 foreach 循环选择最佳线程数方面通常很好（但并不完美）。没有明确保证特定 foreach 循环将使用多少线程（甚至将并行运行），因此可以想象多个 Parallel.ForEach 循环实际上会增强您的表现。最好的检查方法是使用调试器查看它在任何给定点实际使用了多少线程。如果这不是您所期望的，您可以检查 Parallel.ForEach 循环中代码的实现（例如）；此时您可以采取其他步骤来尝试提高性能（例如，针对 IO 绑定和其他非 CPU 绑定操作的良好异步/等待实现，以便线程可以做更多工作 - 见下文）。

简单示例：假设您有一个系统，其中有 4 个线程和 4 个内核，并且 4 个线程是系统上唯一运行的东西。 （显然这永远不会发生）。从调度的角度来看，明智的做法是让每个核心处理一个线程。假设每个线程一直都很忙（即它永远不会坐在那里等待）如何添加额外的线程来提高你的性能？例如，如果您开始运行 6 个线程，那么显然至少一个内核现在必须运行至少 2 个线程，这会增加额外的开销而没有明显的好处。这里的简化（并且可能是不正确的）假设是您的任务是 100% 受 CPU 限制的，并且线程实际上是在单独的内核上运行的。如果其中一个假设不正确，那么这显然是一个增强的机会。例如，如果一个线程花费大量时间等待 IO 绑定操作的结果，那么 CPU 上的多个线程实际上可以提高性能。您还可以考虑使用 async/await 实现来提高性能。

关键是在某些时候添加额外的线程不会给您带来任何性能优势，只会增加开销（例如，特别是如果所涉及的任务主要受 CPU 限制，而不是主要受 IO 限制）。没有办法绕过这个事实。

非 CPU 绑定操作（例如，IO 绑定任务，例如调用服务器），其中主要阻塞等待来自 CPU/内存外部的结果的并行化方式不同。事实上，async/await 不一定 一定要创建新线程；它的主要行为之一是将控制权返回给相关方法的调用者，并在可能的情况下“尝试”在同一线程上执行其他工作。

重复我最喜欢的类比，假设您作为 10 人小组的一部分出去吃饭。当服务员过来点菜时，服务员要求点的第一个人还没准备好，其他九个人已经准备好了。服务员的正确做法是，与其等第一个人准备好点菜，不如让其他 9 个人先点菜，然后如果第一个人准备好了，再让他点菜。他确实不请了第二个服务员来等待那个人准备好。在这种情况下，第二个服务员实际上可能不会减少完成订单所需的总时间。这基本上是 async/await 试图完成的；例如，如果所有操作都在等待来自服务器的结果，那么理想情况下，您可以在它等待的同时做其他事情。

另一方面，为了扩展类比，绝对不是服务员真正自己做饭的情况。在这种情况下，增加更多的人（以此类推，线程）会真正加快速度。

进一步扩展这个类比，如果厨房只有一个四头炉灶，那么在厨房工作人员遇到炉灶大小所施加的硬性限制之前，您可以添加多少人到厨房工作人员中是有硬性限制的.一旦你达到了这个限制，更多的厨房工作人员实际上会减慢速度，因为他们只会互相妨碍，因为一次可以实际烹饪的东西的数量是有硬性限制的。无论你的厨房工作人员有多大，你不可能一次在炉子上烹饪超过 4 种食物。在这种情况下，您拥有的核心数量就像厨房的大小；一旦达到某个点，添加更多厨房人员（线程）会降低您的性能（而不是提高性能）。

Answer 2

如果您使用 RDBMS 支持的模型，最好对模型执行一些 SQL 以快速完成任务，而不是使用 EA 的 API。

https://leanpub.com/InsideEA 有很多关于结构的细节。

例如使用 SQLServer，使用原始 INSERT 将比遍历 EA 对象快得多，更不用说使用 JOIN 快速获取数据了。

我的脚本使用 SQL 的性能比使用 API 高近 100 倍以上。

不确定 EA COM 对象是否能够如您所愿地被调用。如果是这样，模型更新仍然必须以某种顺序发生，才能正确分配 Object_ID。这可以解释为什么你会在某种锁定限制下运行。