我正在使用第三方API执行我认为在使用的时间/资源（图像识别等）方面的昂贵操作。有什么告诉迹象表明应该使用测试代码来使用线程来提高性能？
我有一个分析器，并将分析我编写的依赖于此API的代码。
由于
答案 0 :(得分：1)
如果您有两个不相同的事件序列，那么请考虑它。如果你必须编写一堆逻辑来确保两个操作不是以其他方式进行，那么通过使两个代码更清晰可以获得回报。
另一方面，如果你发现，在尝试制作多线程的东西时，你必须添加大量代码来在线程之间传递结果，因为一个（或两个）在没有其他信息的情况下无法继续，这是一个很好的迹象，表明你试图在他们不有意义的地方创建线程。
有一种情况是，即使你必须添加通信来进行多线程也是有意义的，当你有一个任务需要保持可用于输入，而另一个需要进行大量计算时。一个线程可以从某个地方轮询输入，当没有可用时阻塞，这样当输入可用时，它会及时响应，并将作业提供给另一个“工作者”线程，这样处理就会一直持续，而不仅仅是当有输入时。
另一件需要考虑的事情是，即使作业“令人尴尬地并行”（即，在并行化部分之间需要很少或根本不需要通信），也存在多线程可能不值得的情况。如果您的CPU可以为不同的内核分配不同的线程，那么通过允许多个内核同时咀嚼工作，多线程将为您提供加速。但是在单核处理器上，或者甚至是具有不幸操作系统的多核处理器上，拥有多个线程都不会加快速度，因为一个核心仍然需要完成所有工作。
答案 1 :(得分：1)
图像处理通常是cpu绑定的。但是，如果您的图像处理API已经设计为利用多个cpu，那么多线程可能对您没有帮助。我通常考虑的用于快速确定多线程是否有帮助的策略是编写一个简单的程序，它一遍又一遍地进行相关处理。然后，我将在一组数据上运行它，然后同时运行该过程的两个实例，每个实例都有一半的数据。没有必要确保数据在这种测试中是均衡的;如果一个进程耗尽，它将只运行一个实例。时间是通过挂钟时间完成的。我的意思是字面意思;选择一个足够大的数据集，至少需要一分钟才能运行，但最好是5分钟或更长时间。
如果同时运行两个副本可以显着提高吞吐量，那么多线程可能是一个好主意。显然，这种策略仅在某些情况下是实用的，在某些情况下，多线程可能涉及以这种技巧无法模仿的方式利用共享输出。但是，这是一个非常简单的测试，很少需要编写很多代码。