CPython的peephole优化器扫描字节码以寻找不可达的代码块——在无条件跳转（JUMP_ABSOLUTE、JUMP_FORWARD、RETURN_VALUE、RAISE_VARARGS）之后没有任何其他分支入口的指令序列。当识别出来时，它会移除这些死代码以减少缓存压力并提高指令密度。
由于Python的异常处理表、循环结构和条件跳转将目标位置存储为对代码对象的**co_code序列的绝对字节偏移，因此优化器必须构建一个重定位映射，跟踪在每个存活指令之前删除了多少字节。然后，它遍历所有跳转指令和异常处理程序范围，通过从目标位置减去累积删除计数来调整它们的目标偏移。这确保了即使在前面的字节码被压缩之后，SETUP_FINALLY块、FOR_ITER**循环和用户定义的跳转也能落在正确的操作码上。
一个数据管道团队注意到，他们的ETL工具的启动脚本包含大量由**if DEBUG:标志保护的调试日志代码块，DEBUG是一个设定为False的模块级常量。尽管条件在静态上为假，编译后的字节码仍然在编译后包含日志逻辑，使得.pyc**文件大小增加了40%，并稍微降低了生产服务器上指令缓存的局部性。
他们评估了三种不同的方法。
第一种，他们考虑使用C预处理器或Jinja2模板在部署前剥离调试代码。此方法可以确保生产环境中没有调试字节码，但引入了复杂的构建步骤依赖，存在诸如开发和生产代码库之间微妙的分歧，增加了调试生产问题的复杂性，因为源代码再也无法与运行的字节码匹配。
第二种，他们评估了将所有调试块重构为子模块中的独立函数，希望未调用的函数不会被加载。然而，Python的导入系统一次性编译整个模块，未调用的函数依然作为代码对象保留在模块的字典中；peephole优化器不执行过程间的死代码消除，因此字节码大小保持不变。
第三种，他们调查了CPython的编译管道，发现peephole优化器自动移除**if False:结构后面的代码，因为编译器在块周围发出无条件跳转，peephole传递删除了不可达的尾部。通过使用dis模块验证RETURN_VALUE或JUMP_FORWARD后面没有死代码，他们确认了优化是有效的。他们选择依赖于这个内置机制，确保DEBUG是一个字面值False**而不是运行时计算变量，这使得编译后的字节码大小减少了35%，而无需额外的工具。
为什么peephole优化器拒绝在前面的跳转目标由计算跳转指令引用时移除不可达代码？
计算跳转根据运行时栈上的值确定其目标，例如在**MATCH**语句或动态调度模式中。由于优化器无法静态地知道哪些偏移可能是目标，因此它必须保守地假设任何指令都可能是入口点。因此，它仅移除通过无条件跳转和控制流图的静态分析证明不可达的代码，保留可能成为动态调度目标的任何区块，以防止未定义行为。
优化器在删除用作跳转占位符的NOP指令时如何处理异常处理程序表（co_exceptiontable）？
当编译器生成之前尚未知晓的前向位置的跳转时，通常会发出**NOP（无操作）指令作为占位符或填充，然后稍后修补跳转目标。在peephole优化期间，这些NOP指令被移除以节省空间。优化器在原始和最终偏移之间保持双向映射。当处理异常表时——它存储try/except块的start、end和handler偏移——它将删除字节的累计增量应用于每个条目。如果NOP落在异常范围内，其移除将使end**偏移向左移动，确保保护的字节码范围保持准确，并在正确的边界捕获异常。
是什么阻止peephole优化器像C编译器那样重新排序独立指令以提高管道效率？
Python的字节码与用于生成回溯的评估栈语义和行号表紧密耦合。重新排序指令——例如，将**LOAD_CONST移到LOAD_NAME之前——可能会在发生异常时改变栈的状态，改变回溯中报告的行号或违反解释器循环所需的栈深度不变性。此外，由于Python允许对框架对象和f_lasti**（指令指针）进行反射，任意的重新排序可能会破坏依赖于确定性偏移到源映射的调试器和分析器。因此，优化器被限制于删除不可达代码和重定向跳转，而不改变可执行指令的相对顺序。