操作码序列（BINARY_SUBSCR、GET_ITER）是否在 CPython 中进行了某种优化？

Question

我正在使用 Python3.5 进行一些基准测试，并且在比较以下代码示例时，我注意到f1的运行速度比f2快 45% 以上：

def f1():
    acc = 0
    a = a_
    for i in a[100:900]:
        acc += i

    return acc

def f2():
    acc = 0
    a = a_
    for i in range(100, 900):
        acc += a[i]

return acc

这对我来说有点违反直觉，因为for i in a[100:900]看起来像是在执行不需要的数据副本。 这在反汇编代码时通过BINARY_SUBSCR操作码的存在得到证实。 这是字节码的相关部分：

  9          12 SETUP_LOOP              34 (to 49)
             15 LOAD_FAST                1 (a)
             18 LOAD_CONST               2 (100)
             21 LOAD_CONST               3 (900)
             24 BUILD_SLICE              2
             27 BINARY_SUBSCR
             28 GET_ITER
        >>   29 FOR_ITER                16 (to 48)
             32 STORE_FAST               2 (i)

您如何解释f1的出色表现？ 序列BINARY_SUBSCR和GET_ITER是否经过某种优化以避免数据复制？

---

下面是完整的测试代码供参考。 我尝试将列表大小增加到 1_000_000 个项目，但f1仍然表现更好。 使用array.array时也是一样。

a_ = list(range(1000))

def f1():
    acc = 0
    a = a_
    for i in a[100:900]:
        acc += i

    return acc

def f2():
    acc = 0
    a = a_
    for i in range(100, 900):
        acc += a[i]

    return acc

from dis import dis
from timeit import timeit

for f in f1,f2:
    dis(f)
    print(timeit(f, number=200000))
    print()

结果：

  6           0 LOAD_CONST               1 (0)
              3 STORE_FAST               0 (acc)

  7           6 LOAD_GLOBAL              0 (a_)
              9 STORE_FAST               1 (a)

  8          12 SETUP_LOOP              34 (to 49)
             15 LOAD_FAST                1 (a)
             18 LOAD_CONST               2 (100)
             21 LOAD_CONST               3 (900)
             24 BUILD_SLICE              2
             27 BINARY_SUBSCR
             28 GET_ITER
        >>   29 FOR_ITER                16 (to 48)
             32 STORE_FAST               2 (i)

  9          35 LOAD_FAST                0 (acc)
             38 LOAD_FAST                2 (i)
             41 INPLACE_ADD
             42 STORE_FAST               0 (acc)
             45 JUMP_ABSOLUTE           29
        >>   48 POP_BLOCK

 11     >>   49 LOAD_FAST                0 (acc)
             52 RETURN_VALUE
5.18372956989333

 14           0 LOAD_CONST               1 (0)
              3 STORE_FAST               0 (acc)

 15           6 LOAD_GLOBAL              0 (a_)
              9 STORE_FAST               1 (a)

 16          12 SETUP_LOOP              37 (to 52)
             15 LOAD_GLOBAL              1 (range)
             18 LOAD_CONST               2 (100)
             21 LOAD_CONST               3 (900)
             24 CALL_FUNCTION            2 (2 positional, 0 keyword pair)
             27 GET_ITER
        >>   28 FOR_ITER                20 (to 51)
             31 STORE_FAST               2 (i)

 17          34 LOAD_FAST                0 (acc)
             37 LOAD_FAST                1 (a)
             40 LOAD_FAST                2 (i)
             43 BINARY_SUBSCR
             44 INPLACE_ADD
             45 STORE_FAST               0 (acc)
             48 JUMP_ABSOLUTE           28
        >>   51 POP_BLOCK

 19     >>   52 LOAD_FAST                0 (acc)
             55 RETURN_VALUE
8.191981540992856

Answer 1

没有特殊的优化来避免数据复制（这样做不安全；毕竟不允许在切片后修改源序列以更改切片的内容）。 索引访问速度很慢（加载序列，索引，一遍又一遍地执行BINARY_SUBSCR ，每次都必须解压缩索引），并且制作list的浅表副本（相对）快（它实际上只是一个memcpy -like操作以及一堆引用计数增量）。

range的循环还涉及每次实际制作索引包装器； 一旦你超出了小的int缓存边界，它实际上每次都必须分配一个int并填充它。相比之下，一旦构建了切片，切片的直接迭代只是递增引用计数并返回现有对象，没有内存开销。

所以你的比较不是“复制一大块list ”到“一个接一个地访问每个元素”，而是“将一大块list作为单个操作复制”到“做大量工作来构建int s，然后一遍又一遍地解压它们，逐个元素地提取list的一大块，每次提取都有字节码解释器的开销”。

重点是， for i in range(len(seq)): ... do stuff with seq[i]...被认为是一种反模式，这不仅仅是因为它更丑陋； 它也慢了很多。