Python允许多种不同的并行处理方法。并行性的主要问题是了解其局限性。我们要么平行IO操作或像图像处理这样的CPU限制任务。

在Python 3.5之前，有两种方法可以并行处理IO绑定操作。本地方法是使用多线程，非本地方法涉及像Gevent这样的框架将并发任务调度为微线程。但是，Python 3.5带来了对并发和本地线程的本地支持asyncio。我很好奇，看看它们在内存占用方面的表现如何。找出的结果如下

准备一个测试床

我找到了github上的一个脚本，演示了一个真实的用例。该脚本在100天前从网页下载公交车票价格并准备处理。内存使用量是使用memory_profiler模块测量的。代码在这个Github仓库中可用。

github：https://github.com/ku3o/python-asyncio-example

memory_profiler：https://pypi.org/project/memory_profiler/

同步

我执行了脚本的单线程版本，作为其他解决方案的基准。内存使用在整个执行过程中非常稳定，显而易见的缺点是执行时间。没有任何平行性，剧本耗时约29秒。

顺序内存使用情况

线程池执行程序

多线程是标准库工具箱的一部分。使用Python 3.5，可以通过ThreadPoolExecutor轻松访问，它提供了一个非常简单的API来平行化现有代码。但是，使用线程有一些缺点，其中之一是内存使用率较高。另一方面，执行速度的显着提高是我们首先想要使用它的原因。这个测试的执行时间是〜17秒。与同步执行约29秒相比，这是一个很大的区别。差异是受IO操作速度影响的变量。在这种情况下，网络延迟。

ThreadPoolExecutor：https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor

使用20个线程的ThreadPoolExecutor内存使用情况  

更正

来自Hacker News的nickcw指出，当max_workers参数为时None，线程数量等于机器上的处理器数量乘以5.在我的情况下，这意味着20个线程。将此设置为100个线程（以匹配请求数量）后，内存使用率会更高：

使用100个线程的ThreadPoolExecutor内存使用情况  

GEVENT

Gevent是并行化的另一种方法，它为Python 3.5之前的代码带来了协程。在引擎盖下，它利用了小型，独立的伪线程“Greenlets”，但也产生了一些内部需求的线程。整体内存占用与多线程非常相似。

伪线程内存使用情况

ASYNCIO

自从Python 3.5发布以来，协程现在可以asyncio作为标准Python库的一部分。利用asyncio我用来aiohttp代替requests。aiohttp是具有requests相同功能和类似API 的异步等价物。

在一般情况下，这是开始在异步一个项目之前，需要考虑的一个点，虽然大部分的IO相关的包—— redis， psycopg2，requests ——有自己的等价物在异步世界。

与asyncio之前相比，内存使用率显着降低。它非常接近没有并行化的脚本的单线程版本。

协程内存使用（asyncio）

那么我们应该开始使用asyncio吗？

并行性是加速具有大量IO操作的应用程序的一种非常有效的方式。就我而言，与顺序处理相比，速度提高了约40％。一旦代码并行运行，并行方法之间速度性能的差异非常小。IO操作在很大程度上取决于其他系统的性能（即网络延迟，磁盘速度等）。因此，并行方法之间的执行时间差异可以忽略不计。

ThreadPoolExecutor和Gevent是非常强大的工具，可以加速现有的应用程序。一个主要的优点是在大多数情况下只需要对代码库进行微小的更改。当谈到整体性能时，性能最好的工具就是asyncio使用本地线程。与其他并行方法相比，内存占用量要低得多，而不会影响总体速度。它带有一个价格，但是代码库和它的依赖关系必须专门设计用于asyncio。将代码库移动到协程时必须考虑这一点。

和我一样，我希望你能从这篇文章中获得关于python的一些有用的知识