Python列表元素与转换为元组以进行字符串格式化

CPython 优化规则通常基于你推送到 C 层（相对于字节码解释器）的工作量以及字节码指令的复杂程度；对于低级别的绝对工作，解释器的固定开销往往会淹没实际工作，因此从较低级别语言的经​​验中得出的直觉并不适用。

不过，它很容易测试，尤其是使用ipython的%timeit魔法（在 WSLv2 下运行的 Alpine Linux 上的 Python 3.8.5 上完成的计时）：

In [2]: %%timeit l = [1, 2, 3]
...: tuple(l)
97.6 ns ± 0.303 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [3]: %%timeit l = [1, 2, 3]
...: (l[0], l[1], l[2])
104 ns ± 0.561 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [4]: %%timeit l = [1, 2, 3]
...: (*l,)
78.1 ns ± 0.628 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [5]: %%timeit l = [1, 2]
...: tuple(l)
96 ns ± 0.895 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [6]: %%timeit l = [1, 2]
...: (l[0], l[1])
70.1 ns ± 0.571 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
In [7]: %%timeit l = [1, 2]
...: (*l,)
73.4 ns ± 0.736 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)


因此，实际上，您给出的代码示例为每种尺寸做出了正确的决定（假设性能最重要）；在两个元素上，索引比替代方案更快，在三个元素上，转换为tuple批量可以节省足够的重复索引以取胜。

只是为了好玩，我在上面包含了一个等效的解决方案，tuple(l)它使用额外的解包泛化来构建tuple使用专用字节码，它展示了如何用专用优化字节码替换通用构造函数调用这样小的事情可以在固定开销。

这个例子有什么额外的乐趣：更快的(*l,)解决方案实际上涉及两个临时对象；BUILD_TUPLE_UNPACK（实现它的字节码）与BUILD_LIST_UNPACK. 他们俩实际上都构建了一个list，并在最后BUILD_TUPLE_UNPACK将其转换为tuple。所以(*l,)躲在另一个拷贝到临时数据结构，但由于特殊的字节码比这么多有效的内置的查找加通用构造函数的代码路径，它仍然获胜。