python - 异步任务的开销是多少？

Question

Closed. This question needs to be more focused。它当前不接受答案。












想要改善这个问题吗？更新问题，使它仅关注 editing this post的一个问题。

2年前关闭。



Improve this question




就内存和速度而言，任何异步任务的开销是多少？在不需要并发运行的情况下，是否有必要将任务数量减到最少？

最佳答案

What is the overhead of any asyncio task in terms of memory and speed?

TL; DR 内存开销似乎可以忽略不计，但是时间开销可能很大，尤其是在等待的协程选择不暂停时。

假设您正在评估与直接等待的协程相比的任务开销，例如:

await some_coro()                       # (1)
await asyncio.create_task(some_coro())  # (2)

没有理由直接写(2)，但是当使用自动 "futurize"接收到的可接收对象的API(例如 asyncio.gather或 asyncio.wait_for)时，创建不必要的任务很容易。 (我怀疑构建或使用这种抽象是该问题的背景。)

测量两个变量之间的内存和时间差很简单。例如，以下程序创建了一百万个任务，并且该进程的内存消耗可以除以一百万以估算任务的内存成本:

async def noop():
    pass

async def mem1():
    tasks = [asyncio.create_task(noop()) for _ in range(1000000)]
    time.sleep(60)  # not asyncio.sleep() in this case - we don't
                    # want our noop tasks to exit immediately

在运行Python 3.7的我的64位Linux计算机上，该进程消耗了大约1 GiB的内存。大约每个任务 1 KiB +协程，它会计算任务的内存及其在事件循环簿记中条目的内存。下面的程序仅测量协程的开销:

async def mem2():
    coros = [noop() for _ in range(1000000)]
    time.sleep(60)

上述过程大约需要550 MiB的内存，或者每个协程仅即可达到 0.55 KiB。因此，看起来虽然任务不是完全免费的，但它并没有在协程上施加巨大的内存开销，尤其要记住上面的协程是空的。如果协程具有某种状态，则开销会小得多(相对而言)。

但是，CPU开销又如何呢？与等待协同程序相比，创建和等待任务需要多长时间？让我们尝试一个简单的测量:

async def cpu1():
    t0 = time.time()
    for _ in range(1000000):
        await asyncio.create_task(noop())
    t1 = time.time()
    print(t1-t0)

在我的计算机上，这需要 27秒(平均，变化很小)才能运行。没有任务的版本如下所示:

async def cpu2():
    t0 = time.time()
    for _ in range(1000000):
        await noop()
    t1 = time.time()
    print(t1-t0)

这只需要 0.16秒，约为170倍!因此，与等待协程对象相比，等待任务的时间开销不可忽略。这有两个原因:

任务比协程对象创建起来要昂贵得多，因为它们需要先初始化基础Future，然后再初始化Task本身的属性，最后将任务插入事件循环中，并拥有自己的簿记功能。

新创建的任务处于挂起状态，其构造函数使用scheduled来在第一个机会开始执行协程。由于该任务拥有协程对象，因此等待新任务不能立即开始执行协程；因此，等待新任务就可以开始执行协程。它必须暂停并等待任务执行。等待的协程将仅在完整的事件循环迭代之后恢复，即使正在等待选择根本不暂停的协程!事件循环迭代是昂贵的，因为它要遍历所有可运行的任务并轮询内核的IO和超时事件。实际上，strace的cpu1显示了对 epoll_wait(2) 的两百万次调用。另一方面，cpu2仅针对偶尔与分配有关的mmap()进入内核，总共有数千个。

相反，除非等待的协程本身决定将暂停，否则直接等待事件循环中的协程doesn't yield。相反，它立即继续运行并开始执行协程，就好像它是普通函数一样。

因此，如果协程的快乐路径不涉及挂起(例如非竞争性同步原语或从具有要提供数据的非阻塞套接字读取流的情况)，则等待它的成本可与函数调用。这比等待任务所需的事件循环迭代快得多，并且在延迟很重要时可以有所作为。

关于python - 异步任务的开销是多少？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55761652/

上一篇：angularjs - 2019年，将一个站点从Angularjs迁移到另一个框架需要多少钱？

下一篇：x86 - 为什么 "i586"指的是 Pentium 1，为什么 "i686"指的是 Pentium Pro？

相关文章：

python - 无法使用 xpath、lxml 从抓取的页面获取脚本标记的内容

python - asyncio.new_event_loop 创建的事件循环挂起

python-3.x - Python 中的多元线性回归机器学习

python asyncio 从 3.4 迁移到 3.5+

python - asyncio 的哪一部分是并发的？想要实现细节

python - 这个排序代码是如何工作的？

python - 不区分大小写的 Python 字符串 split() 方法

Python:读取由API动态生成的csv文件？

python - 从内部添加和删除实例到列表

python - 使用 AIOfile 读取异步文件

Answer 1

What is the overhead of any asyncio task in terms of memory and speed?

TL; DR 内存开销似乎可以忽略不计，但是时间开销可能很大，尤其是在等待的协程选择不暂停时。

假设您正在评估与直接等待的协程相比的任务开销，例如:

await some_coro()                       # (1)
await asyncio.create_task(some_coro())  # (2)

没有理由直接写(2)，但是当使用自动 "futurize"接收到的可接收对象的API(例如 asyncio.gather或 asyncio.wait_for)时，创建不必要的任务很容易。 (我怀疑构建或使用这种抽象是该问题的背景。)

测量两个变量之间的内存和时间差很简单。例如，以下程序创建了一百万个任务，并且该进程的内存消耗可以除以一百万以估算任务的内存成本:

async def noop():
    pass

async def mem1():
    tasks = [asyncio.create_task(noop()) for _ in range(1000000)]
    time.sleep(60)  # not asyncio.sleep() in this case - we don't
                    # want our noop tasks to exit immediately

在运行Python 3.7的我的64位Linux计算机上，该进程消耗了大约1 GiB的内存。大约每个任务 1 KiB +协程，它会计算任务的内存及其在事件循环簿记中条目的内存。下面的程序仅测量协程的开销:

async def mem2():
    coros = [noop() for _ in range(1000000)]
    time.sleep(60)

上述过程大约需要550 MiB的内存，或者每个协程仅即可达到 0.55 KiB。因此，看起来虽然任务不是完全免费的，但它并没有在协程上施加巨大的内存开销，尤其要记住上面的协程是空的。如果协程具有某种状态，则开销会小得多(相对而言)。

但是，CPU开销又如何呢？与等待协同程序相比，创建和等待任务需要多长时间？让我们尝试一个简单的测量:

async def cpu1():
    t0 = time.time()
    for _ in range(1000000):
        await asyncio.create_task(noop())
    t1 = time.time()
    print(t1-t0)

在我的计算机上，这需要 27秒(平均，变化很小)才能运行。没有任务的版本如下所示:

async def cpu2():
    t0 = time.time()
    for _ in range(1000000):
        await noop()
    t1 = time.time()
    print(t1-t0)

这只需要 0.16秒，约为170倍!因此，与等待协程对象相比，等待任务的时间开销不可忽略。这有两个原因:

任务比协程对象创建起来要昂贵得多，因为它们需要先初始化基础Future，然后再初始化Task本身的属性，最后将任务插入事件循环中，并拥有自己的簿记功能。

新创建的任务处于挂起状态，其构造函数使用scheduled来在第一个机会开始执行协程。由于该任务拥有协程对象，因此等待新任务不能立即开始执行协程；因此，等待新任务就可以开始执行协程。它必须暂停并等待任务执行。等待的协程将仅在完整的事件循环迭代之后恢复，即使正在等待选择根本不暂停的协程!事件循环迭代是昂贵的，因为它要遍历所有可运行的任务并轮询内核的IO和超时事件。实际上，strace的cpu1显示了对 epoll_wait(2) 的两百万次调用。另一方面，cpu2仅针对偶尔与分配有关的mmap()进入内核，总共有数千个。

相反，除非等待的协程本身决定将暂停，否则直接等待事件循环中的协程doesn't yield。相反，它立即继续运行并开始执行协程，就好像它是普通函数一样。

因此，如果协程的快乐路径不涉及挂起(例如非竞争性同步原语或从具有要提供数据的非阻塞套接字读取流的情况)，则等待它的成本可与函数调用。这比等待任务所需的事件循环迭代快得多，并且在延迟很重要时可以有所作为。