PyPy3 能加速纯 Python 数值计算、小对象高频创建/销毁、无 C 扩展调用的深层循环逻辑，对类型稳定且热点路径明确的代码可提速 2–5 倍；但调用 numpy 等 C 扩展、含动态特性（eval/exec/inspect）或 I/O 占比高的代码则无效甚至更慢。
PyPy3 对纯 Python 算法逻辑的加速效果高度依赖于代码结构——它不是“换解释器就变快”，而是对特定模式（如大量小对象、循环密集、无 C 扩展调用）有显著收益；实际项目中，部分算法可提速 2–5 倍，但也有不少场景反而更慢或无法运行。
PyPy3 能加速哪些 Python 代码？
PyPy3 的 JIT 编译器只对“反复执行的热点路径”生效，且要求代码能被静态分析出类型行为。它最擅长加速：
- 含深层嵌套
for循环、且循环体内部不频繁切换类型（比如始终操作int或float）的数值逻辑 - 大量创建/销毁小对象的场景（如模拟器、解析器、树遍历），PyPy 的 GC 和内存分配比 CPython 高效得多
- 不含 C 扩展模块（如
numpy、cv2、torch）的纯 Python 实现——一旦调用这些，PyPy 会退回到慢速路径甚至报错 - 递归深度适中（
sys.setrecursionlimit默认值更低）、未使用inspect/frame相关调试功能的代码
为什么你的代码在 PyPy3 上没变快，甚至报错？
常见失效原因不是“PyPy 不行”，而是代码触发了它的短板：
-
ImportError: No module named 'numpy'：PyPy3 默认不带numpy，需用pypy3 -m pip install numpy安装兼容版（性能通常仍不如 CPython + OpenBLAS） - 用了
__import__、exec、eval或动态修改类属性（如type(...).__dict__），JIT 会直接禁用优化 - 函数内频繁调用
print()、logging.debug()或其他 I/O，I/O 开销占比变高，掩盖了计算加速 - 算法本身是
O(n²)且n很小（比如n ），JIT 编译预热时间（首次运行慢）反而拖累整体耗时
实操：验证和启用 PyPy3 加速的最小闭环
别直接替换生产环境。先用这个模板测真实收益：
立即学习“Python免费学习笔记（深入）”；
import time
def hot_loop(n):
s = 0
for i in range(n):
if i % 7 == 0:
s += i * i
return s
<h1>关键：让 JIT 有足够次数“看到”热点</h1><p>start = time.time()
for _ in range(5): # 至少跑 3–5 次
hot_loop(10**6)
end = time.time()
print(f"PyPy3 耗时: {end - start:.3f}s")
- 第一次运行一定慢（JIT 编译），后续才体现加速；所以必须循环多次再计时
- 对比时，用同一台机器、同一份源码，在 CPython3 下跑完全相同逻辑（注意：CPython 下不用循环多次，否则 cache 效应失真）
- 若 PyPy3 版本输出耗时比 CPython 低 30% 以上，说明该逻辑适配良好；否则优先考虑算法重构或
@njit等替代方案
PyPy3 的加速边界很清晰：它救不了 IO 密集、C 扩展依赖重、或动态性过强的代码。真正容易被忽略的是——你得亲手让它“热起来”，而不是指望它自动飞升。
