与多线程相比,多处理是否加快了文件传输速度

如果以下假设成立:

1. 您的脚本只是从网络接收数据并逐字(或多或少地)将数据写入磁盘,即它不会对数据进行任何昂贵的处理
2. 您的脚本运行在具有典型现代网络硬件(如千兆以太网或更慢的)的现代CPU上
3. 您的脚本下载例程并不是非常低效(例如,您正在接收大小合理的数据块,而不是一次只接收一个字节或诸如此类的傻事)

... 那么你的下载速度就不太可能受到CPU的限制了。瓶颈很可能是网络带宽或磁盘I/O带宽。

在任何情况下,由于AFAICT您的用例是令人尴尬的并行的(即各种下载不必相互通信或交互,它们只是各自独立地做自己的事情),所以使用多线程与多处理在性能方面不太可能有太大的不同。当然,唯一确定的方法是两种方法都尝试,并测量每种方法的吞吐量。

简短的回答 一般来说, 这取决于你的工作量。 如果你是认真的表现,请提供细节。例如,是否将图像存储到磁盘,图像大小是否为>1GB与否,等等。

注意:一般来说,如果不是任务关键型的,这两种方法都是可以接受的,因为我们可以使用threading.Thread和multiprocessing.Process轻松地在多线程和多进程实现之间切换。

更多评论 似乎不是CPU而是IO将成为瓶颈。

如果你的文件传输速度不是特别慢——比把数据写到磁盘慢,多线程/多处理就没用了。我所说的文件传输是指用一个硬盘下载图像并将其写入本地计算机。

另一方面,如果您对这些图像进行一些CPU密集型的预处理,然后将它们保存到磁盘上,多线程将非常有用。

一般来说:

多线程-更容易在单个应用程序中使用,因为所有线程共享单个进程的虚拟地址空间,并且可以轻松地相互通信。另一方面,单个进程的虚拟地址空间有限(在32位计算机上小于4GB)。

多处理—更难在单个应用程序中使用(需要进程间通信),但更具可扩展性和更健壮性(如果文件传输进程崩溃,则只有单个文件传输失败)+要使用更多的虚拟地址空间。