性能

构建回归测试套件¶

在开始调整之前，为您的代码构建一个回归测试套件。这会预先投入大量工作，但意味着您可以尝试大量优化，而无需过多担心引入功能性错误。

测量，不要猜测¶

人类不善于猜测或直觉代码中的热点在哪里。测量，不要猜测；使用 分析器 来确定代码花费 80% 时间的 20% 代码，然后对其进行加速调整。

测量将节省您大量浪费在调整实际上并非瓶颈的代码部分上的精力。

在您调整时，经常重新分析，以便您可以看到最热点的变化。

I/O 绑定不同于计算绑定¶

注意计算绑定代码（由于执行大量指令而速度慢）和 I/O 绑定代码（由于磁盘或网络延迟而速度慢）之间的区别。

预计从优化计算绑定代码中获得大部分收益。通常（但并非总是）当 分析 显示应用程序的大部分时间都花在网络和磁盘 I/O 上时，表明您已接近值得调整的结束。

首先调整您的算法¶

通常，当您的代码执行与数据集中大小成 O(n**2) 或更大的操作时，这些操作的成本将超过您使用此处描述的技巧所能获得的任何微小收益。

首先调整您的算法。在您认为已优化了本质上昂贵的操作之后，才考虑应用我们的微调技巧列表。

也就是说，要做好在微调时发现更隐藏的算法问题的准备。您可能会多次经历这个循环。

专注于紧密循环¶

高时间成本极有可能潜伏在紧密循环中一些看似无害的代码中 - 特别是在执行搜索/匹配/查找操作或任何类型的图遍历的代码中。

在计算密集型代码中，最常见的性能杀手是隐藏在 O(n) 循环中的 O(n**2) 操作，它伪装成某种 O(n) 查找或匹配。

另一个常见的耗时操作是在紧密循环中执行的相对昂贵的通用设置操作，这些操作可以移到循环开始之前。（有关此的代表性案例，请参阅有关正则表达式编译的微调技巧。）

小即是快¶

现代计算机具有多个级别的内存缓存，其中一些直接位于处理器芯片上。在任何级别上导致缓存未命中都会产生与下一个外层（更慢）缓存的随机访问时间成正比的性能损失。

因此，小即是快。工作集足够小以适合快速缓存的程序或例程将与该缓存一样快。为了使您的代码更快，请通过使其更简单来减少它生成的 Python 或 JIT 编译器操作码序列的长度。

这里的权衡是算法调整通常以时间换空间——也就是说，它通过包含预计算或表或反向映射来增加算法工作集的大小，以避免 O(n**2) 操作。

无法提前预测这种权衡的最佳点在哪里。您必须尝试不同的方法并进行测量——这让我们回到了“测量，不要猜测”。您的回归测试套件的另一个功能可以作为速度基准。

保持简单¶

简单胜过复杂。PyPy JIT 并不十分智能；您的代码越简单，运行速度就越快。但是，您再次面临权衡：您可能需要付出更多算法复杂性的代价，以避免 O(n**2) 或更糟的暴力操作。

以简单的方式编写普通代码。PyPy JIT 有许多针对不常见使用模式的常见使用模式进行优化的生产。

全局变量¶

在 CPython 中，全局变量和函数（包括包导入）比局部变量的引用要昂贵得多；避免使用它们。（这也是良好的模块化实践）。

CPython 全局引用的成本很高，例如，如果您在频繁访问的内部循环中具有大量使用 int() 的代码，那么在封闭块中使用“int = int”创建局部副本可能值得。

但是，这在 JIT 的 PyPy 代码中不适用。“int = int”技巧不会为您带来性能提升，它只是一个额外的副本。避免全局变量的模块化原因仍然有效。

正则表达式¶

正则表达式编译很昂贵。如果搜索、匹配或替换操作中的正则表达式模式是静态的（在运行时不会发生变异），请重构以使其只执行一次。

如果正则表达式编译在类方法中，请考虑将其作为正则表达式值的静态（共享）类成员的初始化器执行，并在您的操作中使用该类成员。

如果正则表达式编译在自由函数中，请考虑将其移动到模块级别并引用生成的正则表达式对象（但请参阅上面关于全局变量的警告）。

旧式类与新式类¶

新式类允许更快的属性访问，并且每个实例占用的核心比旧式类少。但是，如果属性名称不是常量，那么大部分优势可能会丢失。例如：x.a = y 甚至 setattr(x, 'a', y) 将比动态版本快得多：setattr(x, 'a' + some_variable, y)。

从新式类和旧式类继承的类非常慢；不惜一切代价避免使用它们。

在 PyPy 中，针对旧式类调用的 isinstance() 在 2.0 之前非常慢。

字符串连接很昂贵¶

在 CPython 中，您可能希望替换

s = head + body + maybe + tail

用以下不太易读的代码替换

s = "%(head)s%(body)s%(maybe)s%(tail)s" % locals()

甚至

s = "{head}{body}{maybe}{tail}".format(**locals())

后两种形式都避免了多次分配的开销。但 PyPy 的 JIT 使得线性代码中中间连接的开销消失，该代码保持连接数量较小、有界且恒定。（并且 locals() 在 PyPy 的 JIT 中相当慢。）

另一方面，在像这样的代码中，其中 foo() 函数返回字符串

for x in mylist:
    s += foo(x)

JIT 无法优化掉中间副本。由于对越来越大的前缀段的重复字符串复制，这段代码实际上是 mylist 字符串总大小的二次方。（对于字节数组，此类代码始终很好，因为在这种情况下 += 是一个就地操作。）

这个

parts = []
for x in mylist:
    parts.append(foo(x))
s = "".join(parts)

可能快得多，因为最后一行中的所有字符串连接只创建了一个新的字符串对象，其中包含一个 C 级别的复制序列（列表操作相对便宜）。

框架自省和跟踪很慢¶

某些函数调用可以禁用 PyPy 的速度选项，这些选项跨越称为“JIT 范围”的周围代码段。

像 PyPy 这样的 JIT 基于这样的假设：唯一值得优化的东西是经常执行的循环。每当解释器进入解释程序中的循环时，JIT 都会记录解释器所做的事情，创建一个跟踪。此跟踪被优化，编译成机器代码，并在循环以跟踪期间观察到的条件命中时执行。此跟踪是一种 JIT 范围。

另一种重要的 JIT 范围是函数，它被视为内联的单位。

请注意，JIT 范围是运行时现象，而不是编译时现象。它不受源代码模块边界的限制。频繁调用的循环或内联函数中的库或外部模块调用将是其 JIT 范围的一部分。

locals()、globals()、sys._getframe()、sys.exc_info() 和 sys.settrace 在 PyPy 中有效，但它们会带来性能损失，这可能会通过禁用封闭 JIT 范围上的 JIT 而变得非常大。

（感谢 Eric S. Raymond 提供以上文字）