摘要

本 PEP 提议创建一个名为 profiling 的新标准库模块，用于在一个单一、连贯的命名空间下组织 Python 的内置性能分析工具。

本 PEP 还提议弃用 profile 模块，这是一个遗留的纯 Python 跟踪分析器。

动机

Python 目前提供了两个跟踪分析器：profile 和 cProfile。profile 模块是用纯 Python 实现的，主要用于教学或子类化，但对于实际使用来说太慢了。cProfile 相反，是用 C 实现的，更适合实际的性能分析场景，尽管由于某些行为差异，它不能完全替代 profile。

这两个都是跟踪分析器，这意味着它们会检测每个函数调用和返回。这种方法会引入显著的运行时开销，并可能禁用某些解释器优化，例如由 PEP 659 引入的优化。此外，cProfile 只观察主线程，这使得它在现代并发 Python 程序中用处不大。令人困惑的是，这些模块的命名暗示 profile 是规范的，而实际上它已经基本过时。

在 Python 3.15 中，一个新的采样分析器在 profile.sample 下引入。这个工具被称为 tachyon，它使用统计采样来推断性能特征，这带来了 零开销的性能分析，并且与现代 Python 解释器配合得更好。它还支持 多线程、异步函数、自由线程构建以及附加到正在运行的进程。尽管有这些优点，但 tachyon 放在 profile.sample 下具有误导性，并掩盖了其重要性。

目前，性能分析工具的组织缺乏一致、可发现的结构。提议的重组旨在更有效地引导用户使用适当的工具，澄清分析器之间的方法论区别，并为未来的扩展奠定基础。

基本原理

这种重组解决了 Python 性能分析工具的几个长期存在的问题。

首先，它通过将所有内置分析器收集到一个单一、命名清晰的命名空间下，提高了 可发现性。目前，性能分析工具分散在命名不一致、关系不清的模块中。通过引入 profiling 模块，用户将拥有一个明确且直观的位置来探索和访问性能分析功能。

其次，该提案通过根据其基础方法命名子模块来增强 清晰度——profiling.tracing 用于确定性跟踪分析器，profiling.sampling 用于统计采样分析器。这种明确的分类使得更容易理解每个工具的行为和局限性，并将 API 与鼓励用户采用的心理模型对齐。

第三，它通过使推荐工具更容易找到和使用，为开发人员提供了 指导。当前的结构可能会误导用户依赖像 profile 这样过时或性能较差的模块，仅仅因为命名优先级。通过 profiling 命名空间及其更清晰的语义，用户更有可能为其特定用例选择合适的分析器，无论是涉及低开销采样还是详细跟踪。

最后，这种结构促进了 可扩展性。通过将性能分析工具整合到统一的命名空间下，引入未来的性能分析功能（例如内存分析器、I/O 分析器或混合工具）变得简单直接，而不会使不相关的模块过载或添加冗余的顶级名称。profiling 模块为此提供了一个自然的归宿。

规范

文档

Python 文档将使用新的 profiling 模块作为性能分析功能的规范入口点。它还将描述跟踪分析器和采样分析器之间的区别，并包含何时最适合使用每种类型的指导。

cProfile 的文档将继续提供，但会链接到新的 profiling 等效项。

向后兼容性

本 PEP 唯一向后不兼容的方面是将来移除 profile 模块，但这将遵循 PEP 387 程序。

安全隐患

无。

被拒绝的替代方案

版权

本文档置于公共领域或 CC0-1.0-Universal 许可证下，以更宽松者为准。