替代方案

我们考虑了一些提高 Python 性能的替代策略，但发现它们并不令人满意。

• Cython，Shedskin：Cython [102] 和 Shedskin [103] 都是 Python 的静态编译器。我们认为这些是针对 CPython 历史上糟糕的性能的有用但有限的解决方法。Shedskin 不支持完整的 Python 标准库 [104]，而 Cython 则需要手动添加 Cython 特定的注释以获得最佳性能。

  像这样的静态编译器对于编写扩展模块而不必担心引用计数很有用，但由于它们是静态的、提前编译器，因此它们无法优化即时编译器在运行时数据告知下考虑的全部代码范围。

• IronPython：IronPython [107] 是在 Microsoft 的 .Net 平台上的 Python。它没有在 Mono [108] 上积极测试，这意味着它基本上只能在 Windows 上使用，因此不适合作为通用的 CPython 替代品。
• Jython：Jython [109] 是 Python 2.5 的完整实现，但明显比 Unladen Swallow 慢（根据测量基准测试慢 3-5 倍），并且不支持 CPython 扩展模块 [110]，这使得大型应用程序的迁移成本过高。
• Psyco：Psyco [65] 是一个针对 CPython 的专门 JIT 编译器，实现为一个扩展模块。它主要提高数值代码的性能。优点：已存在；使某些代码运行更快。缺点：仅限 32 位，没有 64 位支持计划；仅支持 x86；非常难以维护；由于对齐问题，与 SSE2 优化的代码不兼容。
• PyPy：PyPy [66] 在数值代码方面具有良好的性能，但在某些工作负载下比 Unladen Swallow 慢。从 CPython 迁移大型应用程序到 PyPy 成本过高：PyPy 的 JIT 编译器仅支持 32 位 x86 代码生成；重要的模块，如 MySQLdb 和 pycrypto，无法在 PyPy 上构建；PyPy 没有提供嵌入式 API，更不用说与 CPython 相同的 API 了。
• PyV8：PyV8 [111] 是一款处于 alpha 阶段的实验性 Python 到 JavaScript 编译器，运行在 V8 之上。PyV8 并未实现完整的 Python 语言，并且不支持 CPython 扩展模块。
• WPython：WPython [105] 是对 CPython 解释器循环的基于词代码的重新实现。虽然它对解释器性能进行了适度的改进 [106]，但它并不是即时编译器的替代品。解释器永远无法像优化的机器代码那样快。我们认为 WPython 和类似的解释器增强功能是对我们工作的补充，而不是竞争对手。

基准测试

Unladen Swallow 开发了一套相当庞大的基准测试套件，范围从旨在测试单个功能的合成微基准测试到整个应用程序的宏基准测试。这些基准测试的灵感分别来自第三方贡献者（例如 html5lib 基准测试）、Google 自身的内部工作负载（slowspitfire、pickle、unpickle），以及在更广泛的 Python 社区中大量使用的工具和库（django、2to3、spambayes）。这些基准测试通过一个名为 perf.py 的单个接口运行，该接口负责收集内存使用信息、绘制性能图表以及对基准测试结果运行统计数据以确保显著性。

完整的可用基准测试列表可在 Unladen Swallow wiki 上找到 [43]，其中包括关于自行下载和运行基准测试的说明。我们所有的基准测试都是开源的；没有任何 Google 专有。我们相信，这套基准测试可以作为衡量任何完整 Python 实现的有用工具，事实上，PyPy 已经在使用这些基准测试进行自己的性能测试 [81]、[96]。我们欢迎这种做法，并希望从 Python 社区获得更多基准测试工作负载。

我们一直致力于收集宏基准测试和尽可能模拟真实应用程序的基准测试，当无法运行整个应用程序时。在另一个维度上，我们的基准测试集合最初侧重于 Google 的 Python 代码（Web 应用、文本处理）所看到的各种工作负载，尽管此后我们扩展了集合以包含 Google 不关心的工作负载。到目前为止，我们一直回避大量数值工作负载，因为 NumPy [80] 已经在这些代码上做得非常出色，因此提高数值性能并不是团队的初始优先事项；我们已开始将此类基准测试纳入集合 [97]，并已开始优化数值 Python 代码。

除了这些基准测试之外，还有一些我们明确不感兴趣的基准测试工作负载。Unladen Swallow 专注于提高纯 Python 代码的性能，因此 NumPy 等扩展模块的性能并不重要，因为 NumPy 的核心例程是用 C 实现的。同样，我们认为涉及大量 IO 的工作负载，如 GUI、数据库或套接字密集型应用程序，无法准确衡量解释器或代码生成优化。也就是说，当然有空间可以提高标准库中 C 语言扩展模块的性能，因此，我们添加了 cPickle 和 re 模块的基准测试。

与 CPython 2.6.4 的性能对比

下面的图表比较了 CPython 2.6.4 和 Unladen Swallow 多次基准测试迭代的算术平均值。perf.py 收集的数据比这多，事实上，算术平均值并非全部内容；为了简洁起见，我们只复制了平均值。我们包含了来自学生双尾 T 检验 [44] 在 95% 置信区间内的 t 分数，以指示结果的显著性。大多数基准测试运行 100 次迭代，但一些运行时间较长的整个应用程序基准测试运行的迭代次数较少。

每个基准测试的描述都可以在 Unladen Swallow wiki 上找到 [43]。

命令

./perf.py -r -b default,apps ../a/python ../b/python

32 位；gcc 4.0.3；Ubuntu Dapper；Intel Core2 Duo 6600 @ 2.4GHz；2 核；4MB L2 缓存；4GB RAM

64 位；gcc 4.2.4；Ubuntu Hardy；AMD Opteron 8214 HE @ 2.2 GHz；4 核；1MB L2 缓存；8GB RAM

许多基准测试在 Unladen Swallow 下都会受到影响，因为当前版本会阻塞执行以将 Python 函数编译为机器代码。例如，这导致了 html5lib 和 rietveld 基准测试的时间线图表中看到的行为，并降低了 2to3 的整体性能。我们有一个活跃的开发分支来解决这个问题（[46]、[47]），但在 CPython 当前线程系统的限制下工作使过程变得复杂，并且需要比最初预期的更多关注和时间。我们认为这个问题对于最终合并到 py3k 分支至关重要。

我们显然没有达到最初设定的 5 倍性能提升的目标。接下来是 性能回顾，其中说明了我们未能达到初始性能目标的原因。我们维护着一个尚未实现的性能工作列表 [50]。

内存使用

下表显示了 Unladen Swallow 的每个默认基准测试在 CPython 2.6.4 和 Unladen Swallow r988 中的最大内存使用量（以千字节为单位），以及基准测试生命周期内的内存使用量时间线。我们包含了 32 位和 64 位二进制文件的表格。内存使用量是在 Linux 2.6 系统上测量的，方法是将内核的 /proc/$pid/smaps 伪文件中的 Private_ 部分相加 [45]。

命令

./perf.py -r --track_memory -b default,apps ../a/python ../b/python

32 位

64 位

内存使用量的增加来自：a) LLVM 代码生成、分析和优化库；b) 本地代码；c) LLVM 中的内存使用问题或泄漏；d) 优化和生成机器代码所需的数据库；e) 尚未分类的其他来源。

虽然自最初的朴素JIT实现[42]以来，我们在减少内存使用方面取得了重大进展，但显然还有更多工作要做。我们相信，在不牺牲性能的情况下，仍然可以节省更多内存。我们一直倾向于专注于原始性能，并且尚未集中精力减少内存使用。我们认为减少内存使用是最终合并到py3k分支的阻碍问题。我们寻求社区关于内存使用增加的可接受水平的指导。

启动时间

静态链接LLVM的代码生成、分析和优化库会增加启动Python二进制文件所需的时间。LLVM使用的C++静态初始化器也会增加启动时间，预编译的C运行时例程的集合（我们希望内联到Python代码中）也会增加启动时间。

Unladen Swallow的startup基准测试结果

$ ./perf.py -r -b startup /tmp/cpy-26/bin/python /tmp/unladen/bin/python

### normal_startup ###
Min: 0.219186 -> 0.352075: 1.6063x slower
Avg: 0.227228 -> 0.364384: 1.6036x slower
Significant (t=-51.879098, a=0.95)
Stddev: 0.00762 -> 0.02532: 3.3227x larger
Timeline: http://tinyurl.com/yfe8z3r

### startup_nosite ###
Min: 0.105949 -> 0.264912: 2.5004x slower
Avg: 0.107574 -> 0.267505: 2.4867x slower
Significant (t=-703.557403, a=0.95)
Stddev: 0.00214 -> 0.00240: 1.1209x larger
Timeline: http://tinyurl.com/yajn8fa

### bzr_startup ###
Min: 0.067990 -> 0.097985: 1.4412x slower
Avg: 0.084322 -> 0.111348: 1.3205x slower
Significant (t=-37.432534, a=0.95)
Stddev: 0.00793 -> 0.00643: 1.2330x smaller
Timeline: http://tinyurl.com/ybdm537

### hg_startup ###
Min: 0.016997 -> 0.024997: 1.4707x slower
Avg: 0.026990 -> 0.036772: 1.3625x slower
Significant (t=-53.104502, a=0.95)
Stddev: 0.00406 -> 0.00417: 1.0273x larger
Timeline: http://tinyurl.com/ycout8m

bzr_startup和hg_startup分别测量Bazaar和Mercurial显示其帮助屏幕所需的时间。startup_nosite多次运行python -S；-S选项的使用并不常见，但我们认为这很好地表明了启动时间增加的来源。

Unladen Swallow在优化启动时间方面取得了进展，但仍有更多工作要做，并需要实施进一步的优化。改进启动时间是Unladen Swallow合并清单中[33]的一个高优先级项目。

二进制文件大小

静态链接LLVM的代码生成、分析和优化库会显著增加python二进制文件的大小。下表报告了剥离后的磁盘二进制文件大小；二进制文件被剥离以更好地对应于系统包管理器使用的配置。我们认为这是对二进制文件大小任何变化的最现实的衡量标准。

二进制文件大小增加是由将LLVM的代码生成、分析和优化库静态链接到python二进制文件中引起的。这可以通过修改LLVM以更好地支持共享链接，然后使用它而不是当前的静态链接来直接解决。但是，目前，静态链接提供了对链接到LLVM的成本的准确了解。

即使在静态链接的情况下，我们也相信仍然有空间通过缩小Unladen Swallow对LLVM的依赖来改进磁盘上的二进制文件大小。这个问题正在积极解决[32]。

性能回顾

我们最初的目标是Unladen Swallow的性能比CPython 2.6提高5倍。我们没有达到这个目标，坦率地说，甚至没有接近。为什么该项目没有达到该目标，基于LLVM的JIT能否达到该目标？

为什么Unladen Swallow没有达到其5倍的目标？主要原因是LLVM需要比我们最初预期的更多工作。基于Apple正在基于LLVM发布产品[82]，以及其他高级语言已成功实现了基于LLVM的JIT（[61]，[63]，[83]），我们假设LLVM的JIT相对没有阻碍性错误。

事实证明这是不正确的。我们不得不将注意力从性能转移到修复LLVM的JIT基础架构中的一些关键错误（例如，[84]，[85]），以及一些不错的增强功能，这些增强功能将能够沿着各个轴进一步优化（例如，[87]，[86]，[88]）。LLVM的静态代码生成工具、工具和优化过程是稳定且经过压力测试的，但即时基础架构则相对未经测试且存在错误。我们已经修复了这个问题。

（我们的假设是，我们遇到了这些问题——其他项目避免的问题——是因为CPython的标准库测试套件的复杂性和彻底性。）

我们还将工程工作从性能转移到支持工具，如gdb和oProfile。gdb根本无法很好地与JIT编译器一起使用，并且LLVM以前没有与oProfile集成。拥有JIT感知的调试器和分析器对项目非常有价值，我们不后悔将时间投入到这些方向。有关更多信息，请参阅调试和分析部分。

基于LLVM的CPython JIT能否达到5倍的性能目标？基于JIT的JavaScript实现的基准测试结果表明，5倍确实是可能的，PyPy的JIT为数值工作负载提供的结果也证明了这一点。Self-92的经验[52]也具有启发意义。

LLVM能否实现这一点？我们相信，我们才刚刚开始了解基于LLVM的JIT能够提供的功能。我们迄今已纳入此系统的优化已取得重大成果（例如，[89]，[90]，[91]）。我们迄今的经验是，Unladen Swallow性能的限制因素是实现文献所需的工程周期。我们发现LLVM易于使用和修改，并且其内置优化极大地简化了实现Python级优化的任务。

进一步的性能机会概述在未来工作部分中讨论。

已知的不兼容性

我们知道唯一一个在Unladen Swallow下无法工作但在CPython 2.6.4下可以工作的应用程序或库是Psyco[65]。我们知道一些库，例如PyGame[79]，它们在CPython 2.6.4下运行良好，但在Unladen Swallow中进行的更改导致其性能有所下降。我们正在跟踪此问题[47]，并努力解决这些性能下降的实例。

虽然Unladen Swallow与CPython 2.6.4源代码兼容，但它与之不兼容二进制文件。针对其中一个编译的C扩展模块需要重新编译才能与另一个一起使用。

Unladen Swallow的合并对WPython等长期存在的CPython优化分支的影响应该很小。WPython[105]和Unladen Swallow在很大程度上是正交的，并且没有技术原因阻止两者都合并到CPython中。使WPython与JIT增强的CPython版本兼容所需的更改应该很少[114]。对于其他CPython优化项目（例如，[115]）也应该是如此。

侵入式分支的CPython，如Stackless Python[116]，支持起来更具挑战性。由于Stackless不太可能合并到CPython[117]，并且任何分支的维护负担都会增加，因此我们认为与Stackless的兼容性是相对较低优先级的。JIT编译的栈帧使用C栈，因此Stackless应该能够像对待通过扩展模块的调用一样对待它们。如果事实证明这是不可接受的，Stackless可以删除JIT编译器或改进JIT代码生成以更好地支持基于堆的栈帧[118]，[119]。

试验对 Python 或 CPython 字节码的更改

Unladen Swallow 的 JIT 编译器在 CPython 字节码上运行，因此它不受仅影响解析器的 Python 语言更改的影响。

我们建议首先在解释器循环中对 CPython 字节码编译器或单个字节码的语义进行原型设计，然后在语义明确后将其移植到 JIT 编译器。为了简化此操作，Unladen Swallow 包含一个 --without-llvm 配置时间选项，该选项会去除 JIT 编译器和所有相关基础设施。这使得当前的实验负担保持不变，以便开发人员可以在当前的低入门门槛的解释器循环中进行原型设计。

Unladen Swallow 开始实现其 JIT 编译器，方法是从字节码实现到 LLVM API 调用的简单、朴素的转换。我们发现这个过程很容易理解，我们建议 CPython 也采用同样的方法。我们在此包含 Unladen Swallow 存储库中的一些示例更改，作为这种开发风格的示例：[26]，[27]，[28]，[29]。

调试

Unladen Swallow 团队对 gdb 进行了更改，使其更容易使用 gdb 调试 JIT 编译的 Python 代码。这些更改在 gdb 7.0 中发布 [17]。它们使 gdb 能够识别并回溯 JIT 生成的调用堆栈帧。这允许 gdb 继续像以前一样用于 CPython 开发，例如，如果正在更改 list 类型或内置函数。

更改后的回溯示例，其中 baz、bar 和 foo 是 JIT 编译的

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in baz ()
#1 0x00002aaaabe7d12c in bar ()
#2 0x00002aaaabe7d0aa in foo ()
#3 0x00002aaaabe7d02c in main ()
#4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70, F=0x14024e0, ArgValues=...)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208

以前，JIT 编译的帧会导致 gdb 错误地回溯，生成大量明显错误的 #6 0x00002aaaabe7d0aa in ?? () 样式的堆栈帧。

亮点

• gdb 7.0 能够正确解析 JIT 编译的堆栈帧，允许在非 JIT 编译的函数（即 CPython 代码库的大部分）上充分使用 gdb。
• 在 JIT 编译的堆栈帧内反汇编会自动打印构成该函数的完整指令列表。这是我们工作之前 gdb 状态的一个进步：开发人员需要猜测函数的起始地址并手动反汇编汇编代码。
• 灵活的基础机制允许 CPython 添加越来越多的信息，并最终达到与 gdb 中 JIT 编译的机器代码的 C/C++ 支持的同等水平。

不足之处

• gdb 无法打印局部变量或告诉您当前在 JIT 编译的函数中执行的哪一行。它也不能单步执行 JIT 编译的代码，除非一次一条指令。
• 尚未与 Apple 的 gdb 或 Microsoft 的 Visual Studio 调试器集成。

Unladen Swallow 团队正在与 Apple 合作，将这些更改合并到他们未来的 gdb 版本中。

性能分析

Unladen Swallow 与 oProfile 0.9.4 及更高版本集成 [18] 以支持 Linux 系统上的汇编级分析。这意味着 oProfile 将在其报告中正确地将 JIT 编译的函数符号化。

示例报告，其中以 #u# 为前缀的符号名称是 JIT 编译的 Python 函数

$ opreport -l ./python | less
CPU: Core 2, speed 1600 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples % image name symbol name
79589 4.2329 python PyString_FromFormatV
62971 3.3491 python PyEval_EvalCodeEx
62713 3.3354 python tupledealloc
57071 3.0353 python _PyEval_CallFunction
50009 2.6597 24532.jo #u#force_unicode
47468 2.5246 python PyUnicodeUCS2_Decode
45829 2.4374 python PyFrame_New
45173 2.4025 python lookdict_string
43082 2.2913 python PyType_IsSubtype
39763 2.1148 24532.jo #u#render5
38145 2.0287 python _PyType_Lookup
37643 2.0020 python PyObject_GC_UnTrack
37105 1.9734 python frame_dealloc
36849 1.9598 python PyEval_EvalFrame
35630 1.8950 24532.jo #u#resolve
33313 1.7717 python PyObject_IsInstance
33208 1.7662 python PyDict_GetItem
33168 1.7640 python PyTuple_New
30458 1.6199 python PyCFunction_NewEx

此支持功能正常，但尚未完善。Unladen Swallow 保持着一个待办事项列表，其中列出了我们认为在 oProfile 集成中进行改进以使其对核心 CPython 开发人员更有用的重要事项 [19]。

亮点

• 在 oProfile 上对 Linux 上的 JIT 帧进行符号化。

不足之处

• 尚未投入工作来改进 Apple 的 Shark [20] 或 Microsoft 的 Visual Studio 分析工具对 JIT 编译的帧的符号化。
• oProfile 输出仍需要一些改进。

我们建议使用 oProfile 0.9.5（及更高版本）来解决 oProfile 中 x86-64 平台上的一个已修复的错误。但是，oProfile 0.9.4 在 32 位平台上可以正常工作。

鉴于将 oProfile 与 LLVM 集成非常容易 [21] 和 Unladen Swallow [22]，其他分析工具也应该很容易，前提是它们支持类似的 JIT 接口 [23]。

我们已经记录了使用 oProfile 分析 Unladen Swallow 的过程 [24]。此文档将在合并时合并到 CPython 的 Doc/ 树中。

在 CPython 中添加 C++

为了使用 LLVM，Unladen Swallow 已将 C++ 引入核心 CPython 树和构建过程中。这是依赖 LLVM 的不可避免的一部分；虽然 LLVM 提供了一个 C API [8]，但它功能有限，无法公开 CPython 所需的功能。因此，我们已使用 C++ 实现 Unladen Swallow JIT 及其支持基础设施的内部细节。我们不建议将整个 CPython 代码库转换为 C++。

亮点

• 轻松使用 LLVM 的完整、强大的代码生成和相关 API。
• 方便的抽象数据结构简化了代码。
• C++ 限于 CPython 代码库的相对较小的角落。
• 可以通过 ./configure --without-llvm 禁用 C++，甚至省略对 libstdc++ 的依赖。

不足之处

• 开发人员必须了解两种相关的语言，C 和 C++，才能处理 CPython 内部结构的全部范围。
• 需要开发和实施 C++ 样式指南。PEP 7 将扩展 [120] 以包含 C++，方法是从 Unladen Swallow [70]、LLVM [71] 和 Google [72] 的 C++ 样式指南中提取相关部分。
• 不同的 C++ 编译器会发出不同的 ABI；如果 CPython 使用一个 C++ 编译器编译，而扩展模块使用另一个 C++ 编译器编译，则可能会导致问题。

管理 LLVM 版本，C++ API 更改

LLVM 每六个月定期发布。这意味着在 CPython 3.x 版本的开发过程中，LLVM 可能会发布两到三次。每次 LLVM 发布都会带来更新、更强大的优化、改进的平台支持和更复杂的代码生成。

LLVM 版本通常包含对 LLVM C++ API 的不兼容更改；LLVM 2.6 的发行说明 [9] 包含一个有意引入的不兼容性列表。在开发过程中，Unladen Swallow 一直紧密跟踪 LLVM 主干。我们的经验是，LLVM API 更改是显而易见的，并且可以轻松或机械地解决。我们在此包含 Unladen Swallow 树中的两个此类更改作为参考：[10]，[11]。

由于 API 不兼容性，我们建议基于 LLVM 的 CPython 目标每次与 LLVM 的单个版本兼容。这将降低核心开发团队的开销。从打包的角度来看，固定到 LLVM 版本不应成为问题，因为预构建的 LLVM 包通常在 LLVM 发布后很快就会通过标准系统包管理器提供，如果没有，llvm.org 本身也包含二进制版本。

Unladen Swallow 历史上在 Unladen Swallow 树中包含 LLVM 和 Clang 源代码树的副本；这样做是为了让我们在对其进行修补时能够紧密跟踪 LLVM 主干。我们不建议 CPython 使用这种开发模型。CPython 版本应基于官方的 LLVM 版本。预构建的 LLVM 包可从 MacPorts [12]（适用于 Darwin）和大多数主要的 Linux 发行版（[13]，[14]，[16]）获取。LLVM 本身提供了其他二进制文件，例如适用于 MinGW 的二进制文件 [25]。

LLVM 目前旨在进行静态链接；这意味着 CPython 的二进制版本将包含 LLVM 的相关部分（并非全部！）。这将增加二进制文件的大小，如上所述。为了简化下游包管理，我们将修改 LLVM 以更好地支持共享链接。此问题将阻止最终合并 [98]。

Unladen Swallow 已指派一名全职工程师在 LLVM 2.7 发布之前修复 LLVM 中任何剩余的关键问题。我们认为 CPython 3.x 能够依赖 LLVM 的已发布版本至关重要，而不是像 Unladen Swallow 一样紧密跟踪 LLVM 主干。我们相信我们将在 LLVM 2.7 发布（预计在 2010 年 5 月）之前完成这项工作 [99]。

构建 CPython

除了对 LLVM 的运行时依赖之外，Unladen Swallow 还包括对 Clang 的构建时依赖 [5]，这是一个基于 LLVM 的 C/C++ 编译器。我们使用它将 C 语言 Python 运行时的部分编译为 LLVM 的中间表示；这使我们能够执行跨语言内联，从而提高性能。Clang 不是运行 Unladen Swallow 的必要条件。大多数主要的 Linux 发行版（例如，[15]）都提供了 Clang 二进制包。

我们检查了 Unladen Swallow 对构建 Python 所需时间的影响，包括配置、完整构建以及修改单个 C 源文件后的增量构建。

完整构建时间受到以下因素的影响：a) LLVM交互需要额外的.cc文件，b) 将LLVM静态链接到libpython中，c) 将Python运行时的部分编译为LLVM IR以启用跨语言内联。

增量构建也比主线CPython略慢。下表显示了修改Objects/listobject.c后增量重建的时间。

与完整构建一样，额外的时间来自将LLVM静态链接到libpython中。如果libpython与LLVM共享链接，则此开销将降低。

应急计划

我们有可能无法将内存使用量或启动时间降低到CPython社区满意的水平。在这种情况下，我们的主要应急计划是从在线即时编译策略转向离线预先编译策略，使用一个带插桩的CPython解释器循环来获取反馈。这与gcc的反馈导向优化（-fprofile-generate)[112]和Microsoft Visual Studio的配置文件引导优化[113]使用的模型相同；在这里，我们将将其称为“反馈导向优化”，或FDO。

我们认为，用于Python的FDO编译器将不如JIT编译器。FDO需要一套高质量、有代表性的基准测试套件，这在开源和闭源开发中都比较罕见。JIT编译器可以动态查找和优化任何应用程序中的热点——无论是否有基准测试套件——使其能够在无需人工干预的情况下适应应用程序瓶颈的变化。

如果需要提前的FDO编译器，它应该能够利用为Unladen Swallow的JIT编译器已经开发的大部分代码和基础设施。实际上，这两种编译策略可以并存。