Python多重处理-为什么使用functools.partial比默认参数慢？

Question

考虑以下功能：

def f(x, dummy=list(range(10000000))):
    return x

如果使用multiprocessing.Pool.imap，则会得到以下计时：

import time
import os
from multiprocessing import Pool

def f(x, dummy=list(range(10000000))):
    return x

start = time.time()
pool = Pool(2)
for x in pool.imap(f, range(10)):
    print("parent process, x=%s, elapsed=%s" % (x, int(time.time() - start)))

parent process, x=0, elapsed=0
parent process, x=1, elapsed=0
parent process, x=2, elapsed=0
parent process, x=3, elapsed=0
parent process, x=4, elapsed=0
parent process, x=5, elapsed=0
parent process, x=6, elapsed=0
parent process, x=7, elapsed=0
parent process, x=8, elapsed=0
parent process, x=9, elapsed=0

现在，如果我使用functools.partial而不是使用默认值：

import time
import os
from multiprocessing import Pool
from functools import partial

def f(x, dummy):
    return x

start = time.time()
g = partial(f, dummy=list(range(10000000)))
pool = Pool(2)
for x in pool.imap(g, range(10)):
    print("parent process, x=%s, elapsed=%s" % (x, int(time.time() - start)))

parent process, x=0, elapsed=1
parent process, x=1, elapsed=2
parent process, x=2, elapsed=5
parent process, x=3, elapsed=7
parent process, x=4, elapsed=8
parent process, x=5, elapsed=9
parent process, x=6, elapsed=10
parent process, x=7, elapsed=10
parent process, x=8, elapsed=11
parent process, x=9, elapsed=11

为什么版本使用functools.partial速度这么慢？

Answer 1

使用multiprocessing要求向工作进程发送有关要运行的功能的信息，而不仅仅是发送要传递的参数。通过在主流程中酸洗该信息，将其发送到工作流程，然后在此处将其取消酸洗，来传输该信息。

这导致了主要问题：

用默认参数腌制一个函数很便宜 ;
它只会腌制函数的名称（加上让Python知道它是一个函数的信息）；工作进程仅查找名称的本地副本。他们已经有了f要查找的命名函数，因此传递它几乎不需要花费任何成本。

但 酸洗partial功能包括酸洗底层函数（便宜）和 所有 的默认参数（ 昂贵的 当默认参数是一个长10M
list）
。因此，在这种partial情况下，每次分派任务时，它都会对绑定的参数进行腌制，然后将其发送给工作进程，工作进程取消处理，然后最终完成“实际”工作。在我的机器上，该泡菜的大小约为50
MB，这是一笔巨大的开销。在我的机器上进行快速时序测试时，腌制和解开1000万个冗长list的文件0大约需要620毫秒（而忽略了实际传输50
MBhtml" target="_blank">数据的开销）。

partial我们必须以这种方式腌制，因为他们不知道自己的名字。当对诸如之类的函数进行酸洗时f，f（being
def-ed）知道了它的限定名称（在交互式解释器中或从程序的主模块中为__main__.f），因此，远程端可以通过等效于来在本地重新创建它from __main__ import f。但是partial不知道它的名字。当然，您已将其分配给g，但本身pickle也不partial知道它具有限定名称__main__.g；它可以被命名foo.fred或一百万个其他东西。因此，必须有pickle必要的信息才能完全从头开始重新创建它。这也是pickle-为每个调用（而不是每个工作人员一次）进行调用，因为它不知道可调用对象在工作项之间的父级中没有更改，并且始终在尝试确保其发送最新状态。

您还有其他问题（list在这种partial情况下，仅会创建定时事件，并且调用partial包装函数与直接调用函数会产生较小的开销），但相对于每次调用的开销酸洗和取消酸洗partial所添加的（相对的初始创建list将一次性费用增加到
每个 泡菜/解开周期成本的一半以下；通过调用的开销partial不到一微秒。