我赢了32 C ++应用程序。我必须将330,000个对象加载到内存中。如果我使用顺序方法，大约需要16分钟。在线程方法中，我将330,000个对象平均分配到10个容器中。我创建了10个线程，并为每个线程分配一个大小为33000个对象的容器，以便将它们加载到内存中。这种方法大约需要9分钟。
增加线程数无济于事.....
如果我使用ThreadPool，我会得到进一步的改进吗？
答案 0 :(得分：3)
一如既往地没有具体细节，取决于。
您是从磁盘加载对象还是在内存中创建它们？如果你是从磁盘上加载它们那么它可能是IO绑定的，因此增加线程数可能无济于事。
在您提到的评论中，您正在从数据库加载。我猜你何时使用线程同时进行N个查询？可能值得调查数据库控制台，以了解它如何处理许多并发查询。
另一方面，如果对象是由某些CPU绑定进程创建的（例如计算pi），则可能增加的线程数比CPU数量增加可能不会提高性能（和ronag一样）由于context switching）的增加，评论中指出可能会损害绩效。
对象之间是否存在依赖关系？这将再次影响事情的进展。
如果您希望以可配置的方式运行独立任务集合，则通常会使用线程池。听起来像使用线程池是一个很好的方法来运行许多基准测试与各种线程设置。您还可以使线程数可配置，这将有助于在不同的体系结构/系统上运行。
答案 1 :(得分：0)
IME和你的，一些线程将加速这种任务。我猜测，由于更好地使用了“智能”产品，整体吞吐量得到了提高。现代控制器上可用的磁盘缓存 - 磁盘/控制器空闲时间较少，因为总有线程想要读取内容。然而，在加载了几个线程并且您受磁盘限制之后，收益递减就会设置。在一个稍微类似的应用程序中，我发现任何超过6个线程都没有提供额外的优势＆amp;只是耗尽了更多的记忆。
我无法看到这些线程的汇集或其他方式如何对性能产生任何影响 - 它只是一项必须完成的大工作：（
告诉您的客户他们必须安装SSD
RGDS， 马丁