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