使用
multiprocessing要求向工作进程发送有关要运行的功能的信息，而不仅仅是发送要传递的参数。通过在主流程中酸洗该信息，将其发送到工作流程，然后在此处将其取消酸洗，来传输该信息。
这导致了主要问题：
用默认参数腌制一个函数很便宜 ;
它只会腌制函数的名称（加上让Python知道它是一个函数的信息）；工作进程仅查找名称的本地副本。他们已经有了
f要查找的命名函数，因此传递它几乎不需要花费任何成本。
但 酸洗partial
功能包括酸洗底层函数（便宜）和 所有 的默认参数（ 昂贵的 当默认参数是一个长10Mlist
）。因此，在这种
partial情况下，每次分派任务时，它都会对绑定的参数进行腌制，然后将其发送给工作进程，工作进程取消处理，然后最终完成“实际”工作。在我的机器上，该泡菜的大小约为50
MB，这是一笔巨大的开销。在我的机器上进行快速时序测试时，腌制和解开1000万个冗长
list的文件
0大约需要620毫秒（而忽略了实际传输50
MB数据的开销）。
partial我们必须以这种方式腌制，因为他们不知道自己的名字。当对诸如之类的函数进行酸洗时
f，
f（being
def-ed）知道了它的限定名称（在交互式解释器中或从程序的主模块中为
__main__.f），因此，远程端可以通过等效于来在本地重新创建它
from__main__ importf。但是
partial不知道它的名字。当然，您已将其分配给
g，但本身
pickle也不
partial知道它具有限定名称
__main__.g；它可以被命名
foo.fred或一百万个其他东西。因此，必须有
pickle必要的信息才能完全从头开始重新创建它。这也是
pickle-为每个调用（而不是每个工作人员一次）进行调用，因为它不知道可调用对象在工作项之间的父级中没有更改，并且始终在尝试确保其发送最新状态。
您还有其他问题（
list在这种
partial情况下，仅会创建定时事件，并且调用
partial包装函数与直接调用函数会产生较小的开销），但相对于每次调用的开销酸洗和取消酸洗
partial所添加的（相对的初始创建
list将一次性费用增加到
每个 泡菜/解开周期成本的一半以下；通过调用的开销
partial不到一微秒。
