我正在开发一个小型库，它使用任务并行库来运行并行搜索解决方案 . 目前的设计符合以下方面：
-
一个ConcurrentQueue接收搜索结果，
-
一个主任务作为循环工作，作为后台线程运行 . 当新解决方案到达队列时，它会将其出列并进行处理，然后在新任务上启动新的搜索，
-
a搜索在其自己的任务中启动，并在完成后将其结果返回到队列 .
[根据Eric J的回答编辑：所涉及的活动完全受CPU限制，没有涉及IO]
该框架目前运作良好 . 但是，我可以完全控制将触发的搜索任务的数量，我的理解是，虽然TPL目前处理的情况非常好，但在系统中推送大量搜索不会导致并行性增加，因为它将受到系统上可用核心数量的限制，并且在一定程度后会变得适得其反 .
我的问题如下：我可以通过限制将要运行的搜索任务的数量来“帮助”TPL，如果是，我将如何确定该上限应该是什么？是否适合基于System.Environment.ProcessorCount限制它？
1 回答
首先，除非这里存在真正的性能问题，否则我会让TPL做到这一点 . 这很擅长 .
如果确实需要控制任务数来解决实际性能问题，则需要了解限制性能的因素 . 你的任务是CPU绑定的吗？ IO绑定？你的物理内存耗尽，导致交换吗？
一旦知道限制因素是什么，您当然可以监视该因素并根据该（运行时）测量值调整运行任务的数量 . 例如，如果您的任务受CPU限制但具有一些IO时间，则基于核心数的硬限制是接近但不是最佳的 . 相反，基于整体CPU利用率限制 . 这假定机器主要用于处理此任务 . 如果不是，手动调整则更加复杂且容易出错 .