本文内容可能会改动，以实际版本为准！
本文是 Faster CPython 计划在 3.12 中实现的主要内容的概要。
跟踪优化器
Python 3.11 提升速度的主要方法是用更快的与上下文相关的操作码（自适应的专门化操作码）替换个别的操作码，下一个大的改进方法是优化多个操作码的运行。
为此，现有的许多高级操作码将被替换成低级操作码，例如，用于检查版本号和引用计数的操作码。这些更简单的操作码更容易进行优化，例如，可以删除冗余的引用计数操作。
这些更底层的操作码还能让我们得到一组适合用于生成机器代码的指令（在 CPython 和第三方 JIT 项目中都适用）。
为了做到这点，解释器循环（interpreter loop）将基于声明性的描述而生成。
这可减少一部分为了保持解释器循环与某些相关函数同步而产生的 bug（mark_stacks、stack_effect 等函数），同时也让我们可以对解释器循环作较大的更改试验。
多线程并行
Python 当前每个进程有一个全局解释器锁（GIL），阻碍了多线程的并行。
PEP-684：peps.python.org/pep-0684
PEP-554：peps.python.org/pep-0554
PEP-684 提出了一个方案，即保证所有的全局状态都是线程安全的，并移动到每个子解释器的全局解释器锁中使用。
PEP-554 提出了让 Python 创建子解释器的方案（目前只是一个 C API 特性），从而实现真正的多线程并行。
Python猫注：PEP-554 早在 2017 年就提出了，目标是落地在 Python 3.8-3.9 版本，然而事与愿违。早在 2019 年的时候，我还翻译了一篇《Has the Python GIL been slain?》。屠刀已挥出，让它再飞一会~~
更多专门化
我们分析了哪些字节码将从专门化中获益最多，计划在 3.12 完成其余的高收益的改进。
较小的对象结构
有许多可以减少 Python 对象结构大小的机会。由于它们被频繁使用，这不仅有利于总体的内存使用，还有利于缓存的一致性。我们计划在 3.12 中实现最有希望的一些想法。
这里有一些向后兼容性与性能之间的权衡问题，可能需要提出一个 PEP 来建立共识。
减少内存管理的开销
我们不仅会减小对象的大小，还会使它们的 layout 更加规则。
这不仅能优化内存的分配及释放，还能在 GC 和重新分配期间加快遍历对象的速度。
API 稳定性
除了前述项目外，开发团队还将提升 CPython 代码库的整体质量：
- 通过减少不同编译阶段的耦合，使编译器更易于维护与测试。
- 积极地在 C 语言级别监控和改进 CPython 测试套的代码覆盖率。
- 改进 Python 性能基准测试套，加入更具代表性的现实世界的负载测试。
- 协助处理 CPython 问题和 PR，特别是与性能有关的问题。
- 增加用于标准基准测试的机器，增加 macOS 和 Windows 的测试结果。
- 继续跟主要的深度使用 Python 内核的项目合作，帮助它们适配 CPython 解释器的更改。
注：文中图片为译者所加。
