与多处理一起使用时，PyTesseract 调用工作非常缓慢

Question

我有一个函数，它接收图像列表并在将 OCR 应用于图像后在列表中生成输出。我有另一个函数通过使用多处理来控制该函数的输入。因此，当我有一个列表（即没有多重处理）时，列表中的每个图像花费了大约 1 秒，但是当我将必须并行处理的列表增加到 4 个时，每个图像花费了惊人的 13 秒。

为了了解问题的真正所在，我尝试创建一个最小的问题工作示例。在这里，我有两个函数eat25 和eat100，它们打开图像name 并将其提供给使用API​​ pytesseract 的OCR。 eat25 执行 25 次，eat100 执行 100 次。

我的目标是在没有多处理的情况下运行 eat100，并在多处理的情况下运行 eat25（有 4 个进程）。从理论上讲，如果我有 4 个独立的处理器（我有 2 个内核，每个内核有 2 个线程，因此 CPU(s) = 4（如果我在这里错了，请纠正我），这应该比 eat100 少 4 倍的时间。

但是当我看到代码在打印“处理 0”4 次后甚至没有响应时，所有理论都被浪费了。单处理器函数eat100 工作正常。

我测试了一个简单的范围立方函数，它在多处理中运行良好，所以我的处理器肯定运行良好。这里唯一的罪魁祸首可能是：

• pytesseract：见this
• 代码错误？我做的不对。

`

from pathos.multiprocessing import ProcessingPool
from time import time 
from PIL import Image
import pytesseract as pt
def eat25(name):
    for i in range(25):
        print('Processing :'+str(i))
        pt.image_to_string(Image.open(name),lang='hin+eng',config='--psm 6')
def eat100(name):
    for i in range(100):
        print('Processing :'+str(i))
        pt.image_to_string(Image.open(name),lang='hin+eng',config='--psm 6')
st = time()
eat100('normalBox.tiff')
en = time()
print('Direct :'+str(en-st))
#Using pathos
def caller():
    pool = ProcessingPool()
    pool.map(eat25,['normalBox.tiff','normalBox.tiff','normalBox.tiff','normalBox.tiff'])
if (__name__=='__main__'):
    caller()
en2 = time()

print('Pathos :'+str(en2-en))

那么，问题到底出在哪里？任何帮助表示赞赏！

编辑： 图片normalBox.tiff 可以找到here。如果人们重现代码并检查问题是否仍然存在，我会很高兴。

Answer 1

我是pathos 作者。如果您的代码需要1s 串行运行，那么在幼稚的并行进程中运行很可能需要更长的时间。使用幼稚的并行处理会产生开销：

1. 必须在每个处理器上启动一个新的 python 实例
2. 您的函数和依赖项需要序列化并发送到每个处理器
3. 您的数据需要序列化并发送到处理器
4. 反序列化也是如此
5. 您可能会遇到来自长寿命池或大量数据序列化的内存问题。

我建议检查一些简单的事情来检查您的问题可能出在哪里：

• 尝试pathos.pools.ThreadPool 使用线程并行而不是进程并行。这可以减少序列化和启动池的一些开销。
• 尝试pathos.pools._ProcessPool 更改pathos 管理池的方式。如果没有下划线，pathos 将池保持为单例，并且需要“终止”来明确终止池。使用下划线，当您删除池对象时，该池将终止。请注意，您的 caller 函数不会 close 或 join（或 terminate）池。
• 您可能希望通过尝试dill.dumps 您尝试并行处理的元素之一来检查您的序列化程度。像大numpy 数组这样的东西可能需要一段时间才能序列化。如果传递的内容很大，您可以考虑使用共享内存数组（即multiprocess.Array 或numpy 数组的等效版本——另请参阅：numpy.ctypeslib）以最小化传递的内容每个进程之间。

后者的工作量更大，但如果您有很多要序列化的内容，可以节省大量资金。没有共享内存池，所以如果你需要走这条路，你必须对单个 multiprocess.Process 对象进行 for 循环。