返回首页
一周热榜
我一直在开发一个 Python 异步库（[Blazeio](https://github.com/anonyxbiz/Blazeio)），并偶然发现了一种令人震惊的简单优化，使得 `asyncio.Event` 看起来像是一个过时的产物。
### *问题*
`asyncio.Event`（以及其他语言中的类似结构）存在两个严重的扩展缺陷：
1. *内存*：它为每个等待者分配<i>一个未来对象</i> → 1M 等待者 = 浪费 48MB 内存。
2. *延迟*：它以<i>逐个唤醒</i>的方式唤醒等待者 - 在全局解释器锁（GIL）下的系统调用复杂度为 O(N)。
### *解决方案：`SharpEvent`*
一个可直接替换的方案：
- *为所有等待者使用一个共享的未来对象* - *O(1) 内存*。
- *在单个操作中唤醒所有等待者* - *O(1) 延迟*。
### *基准测试*
| 指标 | `asyncio.Event` | `SharpEvent` |
|--------------|-----------------|--------------|
| 1K 等待者 | ~1ms 唤醒 | *~1µs* |
| 1M 等待者 | *崩溃* | *仍然 ~1µs* |
| 内存 (1M) | 48MB | *48 字节* |
### *为什么这很重要*
- *实时应用*（WebSockets、游戏）获得了*可预测的延迟*。
- *高并发*（物联网、交易）变得简单。
- 它是*纯 Python*，但性能超过了 CPython 的 C 实现。
### *没有缺点？*
几乎没有。如果你需要每个等待者的超时/取消功能，你需要一个包装器，但 99% 的使用场景只需要批量唤醒。
### *试试吧*
```python
from Blazeio import SharpEvent
event = SharpEvent()
event.set() # 立即唤醒所有等待者
```
[GitHub](https://github.com/anonyxbiz/Blazeio)
<i>欢迎反馈，我是否遗漏了关键的使用场景？</i>
Krod AI 是一个研究助手，旨在构建能够消除模糊性并提供清晰帮助的工具。<p>kroskod.com