我有一个 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,这值得制作 dict 的成本。
正如我预测的那样,一旦填充了目录内容,它就会快得多。但是,只有在不使用多处理时才会出现这种情况。我允许用户切换多处理模式,当 directoryContents 为 None 时,这比预期的更快。(即,当我们通过使用 os.path.exists 检查它们的存在来查找文件时)但是,当检查它们的 dict 时,在 multiprocessing.Pool 中调用 CompleteSN 非常慢,大约不到 10 个 SN/秒. (与不使用多处理时的数千个相比)我对正在发生的事情的最佳猜测是,Python 用于在池工作者(我认为有 8 个)之间共享数据的任何机制都被如此大的 dict 结构所困扰。谁能帮我了解这里发生了什么?