众所周知，Python 3.11 版别带来了较大的功能提高，可是，它详细在哪些方面上得到了优化呢？除了闻名的“香农方案”外，它还包括哪些与功能相关的优化呢？本文将带你一探终究！

作者：Beshr Kayali

译者：豌豆花下猫@Python猫

英文：log.beshr.com/python-311-…

转载请保存作者及译者信息！

Python 3.11 在几天前发布了，它按例带来了许多新特性，例如异常组、细粒度的过错位置与堆栈回溯、规范库对 TOML 的解析支持，当然，还有备受我们等待的由 faster CPython 项目带来的速度提高。

根据 pyperformance 的基准测验，CPython 3.11 比 CPython 3.10 平均快 25%。这项改善的原因之一是 Guido 命名的“香农方案”（即 faster CPython）。关于 3.11 版别，这个方案在两个主要方向进行了大量优化：启动时和运行时。

除此之外，Python 3.11 还包括有其它的优化，这些优化不属于香农方案。

在本文中，我将详细介绍 3.11.0 稳定版中惯例优化的细节（即非 faster CPython 项目的改善）。

（译注：作者表明将另写一篇文章介绍 faster CPython 的改善细节，到时，我也将持续翻译，敬请等待！）

目录

  • 优化了一些 printf 风格 % 的格式化代码
  • 优化了 Python 大整数的除法
  • 优化了数字 PyLongs 求和
  • 精简列表的扩容操作，提高了 list.append 功能
  • 减少了全 unicode 键的字典的内存占用
  • 提高了运用asyncio.DatagramProtocol 传输大文件的速度
  • 关于 math 库：优化了 comb(n, k) 与 perm(n, k=None)
  • 关于 statistics 库：优化了 mean(data)、variance(data, xbar=None) 与 stdev(data, xbar=None)
  • 纯 ASCII 字符串的 unicodedata.normalize()，提高到常数时刻

优化了一些 printf 风格 % 的格式化代码

运用格式化的字符串字面量（formatted string literals）是最快的格式化字符串的办法。

Python 3.10 中的一个简略基准测验：

$ python -m pyperf timeit -s \
  'k = "foo"; v = "bar"' -- '"%s = %r" % (k, v)'
.....................
Mean +- std dev: 187 ns +- 8 ns

可是运用 f-string 似乎要快 42%：

$ python -m pyperf timeit -s \
  'k = "foo"; v = "bar"' -- 'f"{k!s} = {v!r}"'
.....................
Mean +- std dev: 131 ns +- 9 ns

优化功能的手段是将简略的 C 风格的格式化办法转换为 f-string 办法。在 3.11.0 中，只转换了 %s、%r 和 %a 三种，可是目前有一个待合入的 pull request，将会支持：%d、%i、%u、%o、%x、%X、%f、 %e、%g、%F、%E、%G。

例如，下面是 Python 3.11 中相同基准测验的成果：

$ python -m pyperf timeit -s \
  'k = "foo"; v = "bar"' -- '"%s = %r" % (k, v)'
.....................
Mean +- std dev: 100 ns +- 5 ns

大约快了 87%！当然，3.11 中其它的优化对此也有影响，比如更快的解说器启动时刻。

优化了 Python 大整数的除法

在 Python 3.10 中：

python -m pyperf timeit -s 'x=10**1000' -- 'x//10'
.....................
Mean +- std dev: 1.18 us +- 0.02 us

在 Python 3.11 中：

python -m pyperf timeit -s 'x=10**1000' -- 'x//10'
.....................
Mean +- std dev: 995 ns +- 15 ns

大约快了18%。

这项优化源自 Mark Dickinson 的一个发现，即编译器总会生成 128:64 的除法指令，虽然处理的是 30 位的数值。

即使在 x64 上，Python 的除法也有些残缺。假设是 30 位数字，则多精度除法所需的基本结构是 64 位除以 32 位的无符号整数除法，产生一个 32 位的商（抱负情况下还会产生一个 32 位余数）。有一个 x86/x64 指令能够做到这一点，也便是 DIVL。可是假如不运用内联汇编，当前版别的 GCC 和 Clang 明显做不到从 longobject.c 中发出该指令——它们只会在 x64 上运用 DIVQ（128 位除以 64 位的除法，虽然被除数的前 64 位被设为零），而在 x86 上则运用固有的 __udivti3 或 __udivti4。

——Mark Dickinson（全文）

优化了数字 PyLongs 求和

这里有一个 issue，它发现 Python 2.7 中 sum 的速度比 Python 3 快得多。不幸的是，在某些条件下，3.11.0 似乎仍然如此。

Python 2.7：

$ python -m pyperf timeit -s 'd = [0] * 10000' -- 'sum(d)'
.....................
Mean +- std dev: 37.4 us +- 1.1 us

Python 3.10：

$ python -m pyperf timeit -s 'd = [0] * 10000' -- 'sum(d)'
.....................
Mean +- std dev: 52.7 us +- 1.3 us

Python 3.11：

$ python -m pyperf timeit -s 'd = [0] * 10000' -- 'sum(d)'
.....................
Mean +- std dev: 39.0 us +- 1.0 us

Python3.10 和 3.11 之间的差异在于，经过在 sum 函数的快速加法分支中内联对单个数字 PyLongs 的解包，能够提高在单个数字 PyLongs 上调用 sum 的功能。这样做能够防止在解包时调用 PyLong_AsLongAndOverflow。

值得注意的是，在某些情况下，Python 3.11 在整数求和时仍然明显慢于 Python 2.7。我们期望在 Python 中经过完成更高效的整数，获得更多的改善。

精简列表的扩容操作，提高了 list.append 功能

在 Python 3.11 中，list.append 有了显著的功能提高（大约快 54%）。

Python 3.10 的列表 append：

$ python -m pyperf timeit -s \
  'x = list(map(float, range(10_000)))' -- '[x.append(i) for i in range(10_000)]'
.....................
Mean +- std dev: 605 us +- 20 us

Python 3.11 的列表 append：

$ python -m pyperf timeit -s \
  'x = list(map(float, range(10_000)))' -- '[x.append(i) for i in range(10_000)]'
.....................
Mean +- std dev: 392 us +- 14 us

关于简略的列表推导式，也有一些小的改善：

Python 3.10：

$ python -m pyperf timeit -s \
  '' -- '[x for x in list(map(float, range(10_000)))]'
.....................
Mean +- std dev: 553 us +- 19 us

Python 3.11：

$ python -m pyperf timeit -s \
  '' -- '[x for x in list(map(float, range(10_000)))]'
.....................
Mean +- std dev: 516 us +- 16 us

译注：记得在 3.9 版别的时候，Python 优化了调用 list()、dict() 和 range() 等内置类型的速度，在不起眼处，竟还能持续优化！

减少了全 unicode 键的字典的内存占用

这项优化令 Python 在运用全为 Unicode 键的字典时，缓存的功率更高。这是由于运用的内存减少了，那些 Unicode 键的哈希会被丢弃，由于那些 Unicode 目标已经有哈希了。

例如，在 64 位平台上，Python 3.10 运行成果：

>>> sys.getsizeof(dict(foo="bar", bar="foo"))
232

在 Python 3.11 中：

>>> sys.getsizeof(dict(foo="bar", bar="foo"))
184

（译注：插个题外话，Python 的 getsizeof 是一种“浅核算”，这篇《Python在核算内存时应该注意的问题？》区分了“深浅核算”，能够让你对 Python 核算内存有更深的理解。）

提高了运用asyncio.DatagramProtocol 传输大文件的速度

asyncio.DatagramProtocol 供给了一个用于完成数据报（UDP）协议的基类。有了这个优化，运用asyncio UDP 传输大文件（比如 60 MiB）将比 Python 3.10 快 100 多倍。

这是经过核算一次缓冲区的巨细并将其存储在一个特点中来完成的。这使得经过 UDP 传输大文件时，asyncio.DatagramProtocol 有着数量级的提速。

PR msoxzw 的作者供给了以下的 测验脚本。

关于 math 库：优化了 comb(n, k) 与 perm(n, k=None)

Python 3.8 在math 规范库中增加了 comb(n, k) 和 perm(n, k=None) 函数。两者都用于核算从 n 个无重复的元素中选择 k 个元素的办法数，comb 回来无序核算的成果，而perm 回来有序核算的成果。（译注：即一个求组合数，一个求摆放数）

3.11 的优化由多个较小的改善组成，比如运用分治算法来完成 Karatsuba 大数乘法，以及尽可能用 C 言语unsigned long long 类型而不是 Python 整数进行comb核算(*)。

另外一项改善是针对较小的 k 值（0 <= k <= n <= 67）：

（译注：以下两段隐晦，暂越过）

关于 0 <= k <= n <= 67, comb(n, k) always fits into a uint64_t. We compute it as comb_odd_part << shift where 2 ** shift is the largest power of two dividing comb(n, k) and comb_odd_part is comb(n, k) >> shift. comb_odd_part can be calculated efficiently via arithmetic modulo 2 ** 64, using three lookups and two uint64_t multiplications, while the necessary shift can be computed via Kummer’s theorem: it’s the number of carries when adding k to n - k in binary, which in turn is the number of set bits of n ^ k ^ (n - k). *

One more improvement is that the previous popcount-based code for computing the largest power of two dividing math.comb(n, k) (for small n) got replaced with a more direct method based on counting trailing zeros of the factorials involved. (*).

Python 3.10：

$ python -m pyperf timeit -s \
  'import math' -- 'math.comb(100, 55)'
.....................
Mean +- std dev: 3.72 us +- 0.07 us
# ---
$ python -m pyperf timeit -s \
  'import math' -- 'math.comb(10000, 5500)'
.....................
Mean +- std dev: 11.9 ms +- 0.1 ms

Python 3.11：

$ python -m pyperf timeit -s \
  'import math' -- 'math.comb(100, 55)'
.....................
Mean +- std dev: 476 ns +- 20 ns
# ---
$ python -m pyperf timeit -s \
  'import math' -- 'math.comb(10000, 5500)'
.....................
Mean +- std dev: 2.28 ms +- 0.10 ms

关于 statistics 库：优化了 mean(data)、variance(data, xbar=None) 与 stdev(data, xbar=None)

3.11 优化了statistics模块中的 mean、variance与stdev 函数。假如入参是一个迭代器，则会直接用于核算，而不是先将其转换为列表。这种核算办法 的速度比之前的快了一倍。*

Python 3.10：

# Mean
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.mean(range(1_000))'
.....................
Mean +- std dev: 255 us +- 11 us
# Variance
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.variance((x * 0.1 for x in range(0, 10)))'
.....................
Mean +- std dev: 77.0 us +- 2.9 us
# Sample standard deviation (stdev)
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.stdev((x * 0.1 for x in range(0, 10)))'
.....................
Mean +- std dev: 78.0 us +- 2.2 us

Python 3.11：

# Mean
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.mean(range(1_000))'
.....................
Mean +- std dev: 193 us +- 7 us
# Variance
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.variance((x * 0.1 for x in range(0, 10)))'
.....................
Mean +- std dev: 56.1 us +- 2.3 us
# Sample standard deviation (stdev)
$ python -m pyperf timeit -s \
  'import statistics' -- 'statistics.stdev((x * 0.1 for x in range(0, 10)))'
.....................
Mean +- std dev: 59.4 us +- 2.6 us

纯 ASCII 字符串的 unicodedata.normalize()，提高到常数时刻

关于 unicodedata.normalize() 办法，假如供给的入参是纯 ASCII 字符串，则经过 unicode 快速查看算法 迅速回来成果。这项查看运用的是PyUnicode_IS_ASCII 完成。

Python 3.10：

$ python -m pyperf timeit -s \
  'import unicodedata' -- 'unicodedata.normalize("NFC", "python")'
.....................
Mean +- std dev: 83.3 ns +- 4.3 ns

Python 3.11：

$ python -m pyperf timeit -s \
  'import unicodedata' -- 'unicodedata.normalize("NFC", "python")'
.....................
Mean +- std dev: 34.2 ns +- 1.2 ns

最后的话：

  • 我写这篇文章是为了加深自己对 Python 3.11 最新成果的知道。假如内容有错，请经过email 或许 Twitter告诉我。（译注：本翻译是出于促进自己学习及加强理解的目的，若有错漏，欢迎指正！）
  • 附 HackerNews 上的评论
  • 鄙人一篇文章中，我将分析 faster CPython 项目带来的优化点。敬请等待！