Python 3.15 的 JIT 回正以后，性能实验最该改的是方法而不是结论

Python

发布日期: 2026-03-31

导语：
截至 2026 年 3 月 31 日，Python 团队如果还把 3.15 的性能讨论停留在“好像快了一点”，就有点浪费官方这几周给出的信息了。3 月 23 日，Python Insider 把 Python 3.15's JIT is now back on track 放到了首页最新位置；更早的 3 月 10 日，Python 3.15.0 alpha 7 说明里明确写出 JIT 在 x86-64 Linux 上几何平均提升 3%-4%，在 AArch64 macOS 上相对 tail-calling interpreter 提升 7%-8%。与此同时，3.15 还带来了新的高频低开销采样 profiler。
这些信息放在一起，最值得团队做的不是直接宣布“Python 3.15 更快”，而是重新设计自己的性能实验方法。

1. 为什么这次性能讨论不能再只跑一套 benchmark

Python 的性能争论最容易犯一个老毛病：挑几个熟悉的用例，跑一轮，出一张图，然后下结论。
3.15 这次不适合这样做。原因有三点：

JIT 改进有明显的平台差异。
Linux x86 和 macOS AArch64 的收益本来就不同。
3.15 同时引入了 profiler、lazy imports、编码默认值等变化。
这些会影响观测方式，也会影响启动与稳态的边界。
真实系统里，性能问题很少只表现成“平均值高低”。
更多时候，它会出现在 warmup、P95、冷启动、容器配额和内存波动里。

如果实验方法不升级，团队很容易拿到一堆“看上去没问题”的数据，却解释不了线上体验为什么还是不稳定。

2. JIT 回正之后，实验设计该怎么改

第一，分架构做实验。
别再拿一台开发机的结果替代全部生产环境。既然官方已经明确不同平台收益不同，团队就应该至少按生产主架构分别建立基线。

第二，分 warmup 阶段做实验。
JIT 相关优化最怕只测一次短跑。你得知道第一次请求、前 100 次请求、稳定运行 10 分钟之后，表现是不是同一回事。

第三，分任务类型做实验。
Web API、CLI、批处理、数据任务、脚本工具，受益方式完全不同。有的更关心启动，有的更关心稳态，有的更关心热点函数。

第四，把 profiler 当正式工具，不是临时工具。
新 profiler 最有价值的地方，不是让你调优更炫，而是让性能排查终于更适合持续集成和定期回归。

3. 一套更靠谱的操作流程

第一步，选三类真实负载。
至少包括一个 Web 服务、一个 CLI 或脚本工具、一个批处理或数据任务。不要只跑微基准。

第二步，固定实验矩阵。
写清楚 Python 版本、架构、操作系统、容器规格、是否启用 JIT、样本规模、warmup 次数。没有矩阵，后面任何结论都不稳。

第三步，把 profiler 输出存成工件。
只看最终耗时不够，要保留热点路径变化。性能实验最值钱的往往不是输赢，而是“为什么变了”。

第四步，区分启动面和稳态面。
lazy imports 这类能力可能让启动更快，但也可能把错误延后到运行时。JIT 也可能需要时间热身。两者一定要分开看。

第五步，和依赖兼容清单一起审。
别只盯 CPython 本身。C 扩展、类型检查、profile hooks、监控 SDK 都可能影响结果。

4. 现在最容易得出的错误结论

一个常见误判是“JIT 已经回正，所以可以准备默认开启”。
不一定。你得先知道自己的工作负载到底从哪一块获益。

另一个误判是“平均提升几个点，就代表升级值回票价”。
很多线上系统更在意尾延迟、初始化时延和资源稳定性，而不是平均数。

5. 建议本周执行的动作

用生产主架构分别建立 3.14 与 3.15a7 的实验矩阵。
把 warmup 和稳态拆成两组指标。
使用新 profiler 保存热点工件。
盘点受 JIT 与 profiler 影响较大的依赖。
在版本例会上只讨论可复现数据，不讨论“感觉快了”。

6. 结语

Python 3.15 这轮性能消息最大的价值，不是它让大家多了一组可喜的数据，而是逼团队把实验方法变得更像工程。JIT 回正了，当然是好事。但真正决定你后面能不能把它用好的，不是 headline，而是你有没有把架构差异、warmup、profiler 和真实负载一起纳入判断。方法一旦变对，结论才开始有意义。