使用 multiprocessing.Pool 时，Python 例程运行得更慢

Question

我有一个 Python 应用程序的子例程，它采用八个字符的序列号列表，并在一组目录中搜索包含这些 SN 的文件名以及一系列可能的扩展名。执行它的函数如下。

def CompleteSN(SNorig, directories, exts, directoryContents=None):

    # Split SNorig into its directory path and basename
    directory, basename = os.path.split(SNorig)

    #Don't try to complete if it has a directory already
    if len(directory) > 0:
        return SNorig

    # Split the basename into extension (ext) and serial number (SN)
    SN = basename[:8].upper()

    #If we have a cache, check it
    if directoryContents is not None:
        if SN in directoryContents:
            return directoryContents[SN]
        else:
            return None

    possSNs = ['.'.join((SN, ext)) for ext in exts]

    for pSN in possSNs:
        for d in directories:
            dpath = os.path.join(d, pSN)
            if os.path.exists(dpath):
                return dpath

    return None

SN 是转换为完整路径的序列号，directories 是要在其中查找它的目录列表，exts 是可能尝试的扩展列表(没有前导点)，directoryContents 是 None 或大(数十万个条目)dict 映射目录中文件的序列号以搜索其全名。我的想法是，对于要完成的大量序列号，将所有可以找到的序列号放入字典中以便快速查找它们会更快，而不是为每个序列号进行系统调用。对于要完成的大量 SN，这将是值得的。

正如我预测的那样，一旦 directoryContents 被填充，它就会快得多。但是，只有在不使用多处理时才会出现这种情况。我允许用户切换多处理模式，当 directoryContents 为 None 时，这比预期的更快。 (即，当我们通过使用 os.path.exists 检查它们的存在来查找文件时)但是，当检查它们的字典时，在 multiprocessing.Pool 中调用 CompleteSN 非常慢，大约低于 10 SN/秒. (与不使用多处理时的数千个相比)我对正在发生的事情的最佳猜测是，无论 Python 用于在池 worker (我认为有 8 个)之间共享数据的任何机制都陷入了如此大的 dict 结构。谁能帮我了解这里发生了什么？

Answer 1

一般来说，您不应该在多个进程之间共享数据结构。同步的开销通常会降低性能。或许您可以创建查找字典的单独副本，每个进程一个？