Почему код с промежуточными переменными быстрее, чем код без них?

Мои результаты были аналогичны вашим: код с промежуточными переменными довольно стабильно был как минимум на 10-20% быстрее в Python 3.4. Однако, когда я использовал IPython в том же самом интерпретаторе Python 3.4, я получил следующие результаты:

In [1]: %timeit -n10000 -r20 tuple(range(2000)) == tuple(range(2000))
10000 loops, best of 20: 74.2 µs per loop

In [2]: %timeit -n10000 -r20 a = tuple(range(2000));  b = tuple(range(2000)); a==b
10000 loops, best of 20: 75.7 µs per loop

Примечательно, что мне никогда не удавалось приблизиться к 74,2 мкс для первого, когда я использовал -mtimeit из командной строки.

Так что этот Heisenbug оказался весьма интересным. Я решил запустить команду с strace и действительно происходит что-то подозрительное:

% strace -o withoutvars python3 -m timeit "tuple(range(2000)) == tuple(range(2000))"
10000 loops, best of 3: 134 usec per loop
% strace -o withvars python3 -mtimeit "a = tuple(range(2000));  b = tuple(range(2000)); a==b"
10000 loops, best of 3: 75.8 usec per loop
% grep mmap withvars|wc -l
46
% grep mmap withoutvars|wc -l
41149

Теперь это хорошая причина для разницы. Код, который не использует переменные, приводит к тому, что системный вызов mmap вызывается почти в 1000 раз чаще, чем тот, который использует промежуточные переменные.

withoutvars заполнено mmap/munmap для региона 256 КБ; одни и те же строки повторяются снова и снова:

mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32e56de000
munmap(0x7f32e56de000, 262144)          = 0
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32e56de000
munmap(0x7f32e56de000, 262144)          = 0
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32e56de000
munmap(0x7f32e56de000, 262144)          = 0

Похоже, что вызов mmap исходит от функции _PyObject_ArenaMmap из Objects/obmalloc.c; obmalloc.c также содержит макрос ARENA_SIZE, который #defined должен быть (256 << 10) (то есть 262144); аналогично munmap соответствует _PyObject_ArenaMunmap из obmalloc.c.

obmalloc.c говорит, что

До Python 2.5 арены никогда не были free() отредактированы. Начиная с Python 2.5, мы пытаемся free() арены и используем некоторые мягкие эвристические стратегии, чтобы увеличить вероятность того, что арены в конечном итоге могут быть освобождены.

Таким образом, эта эвристика и тот факт, что распределитель объектов Python освобождает эти свободные арены, как только они опустошаются, приводят к python3 -mtimeit 'tuple(range(2000)) == tuple(range(2000))' запуску патологического поведения, когда одна область памяти размером 256 КБ многократно перераспределяется и освобождается; и это распределение происходит с mmap/munmap, что сравнительно дорого, поскольку это системные вызовы — более того, mmap с MAP_ANONYMOUS требует, чтобы вновь сопоставленные страницы были обнулены — хотя Python это не заботит.

Поведение отсутствует в коде, который использует промежуточные переменные, потому что он использует немного больше памяти, и никакая область памяти не может быть освобождена, так как некоторые объекты все еще выделены в ней. Это потому, что timeit превратит его в петлю, мало чем отличающуюся от

for n in range(10000)
    a = tuple(range(2000))
    b = tuple(range(2000))
    a == b

Теперь поведение таково, что и a, и b останутся связанными до тех пор, пока они не будут *переназначены, поэтому во второй итерации tuple(range(2000)) выделит третий кортеж, а назначение a = tuple(...) уменьшит счетчик ссылок старого кортежа, в результате чего он будет выпущено и увеличить количество ссылок нового кортежа; то же самое происходит с b. Поэтому после первой итерации всегда есть как минимум 2 таких кортежа, если не 3, так что перебора не происходит.

В частности, нельзя гарантировать, что код, использующий промежуточные переменные, всегда будет быстрее — действительно, в некоторых установках может случиться так, что использование промежуточных переменных приведет к дополнительным вызовам mmap, тогда как код, который напрямую сравнивает возвращаемые значения, может подойти.

Кто-то спросил, почему так происходит, когда timeit отключает сборку мусора. Действительно, timeit делает это:

Примечание

По умолчанию timeit() временно отключает сборку мусора на время. Преимущество этого подхода в том, что он делает независимые тайминги более сопоставимыми. Этот недостаток заключается в том, что GC может быть важным компонентом выполнения измеряемой функции. Если это так, GC можно повторно включить в качестве первого оператора в строке установки. Например:

Однако сборщик мусора Python предназначен только для удаления циклического мусора, т. е. коллекций объектов, ссылки на которые образуют циклы. Здесь это не так; вместо этого эти объекты немедленно освобождаются, когда счетчик ссылок падает до нуля.

Первый вопрос здесь должен быть, это воспроизводимо? Для некоторых из нас, по крайней мере, это определенно так, хотя другие люди говорят, что не видят эффекта. Это в Fedora, когда проверка на равенство изменена на is, поскольку фактическое сравнение кажется нерелевантным для результата, а диапазон увеличен до 200 000, поскольку это, кажется, максимизирует эффект:

$ python3 -m timeit "a = tuple(range(200000));  b = tuple(range(200000)); a is b"
100 loops, best of 3: 7.03 msec per loop
$ python3 -m timeit "a = tuple(range(200000)) is tuple(range(200000))"
100 loops, best of 3: 10.2 msec per loop
$ python3 -m timeit "tuple(range(200000)) is tuple(range(200000))"
100 loops, best of 3: 10.2 msec per loop
$ python3 -m timeit "a = b = tuple(range(200000)) is tuple(range(200000))"
100 loops, best of 3: 9.99 msec per loop
$ python3 -m timeit "a = b = tuple(range(200000)) is tuple(range(200000))"
100 loops, best of 3: 10.2 msec per loop
$ python3 -m timeit "tuple(range(200000)) is tuple(range(200000))"
100 loops, best of 3: 10.1 msec per loop
$ python3 -m timeit "a = tuple(range(200000));  b = tuple(range(200000)); a is b"
100 loops, best of 3: 7 msec per loop
$ python3 -m timeit "a = tuple(range(200000));  b = tuple(range(200000)); a is b"
100 loops, best of 3: 7.02 msec per loop

Я отмечаю, что различия между запусками и порядком выполнения выражений очень мало влияют на результат.

Добавление присваиваний a и b в медленную версию не ускоряет ее. На самом деле, как и следовало ожидать, присваивание значения локальным переменным имеет незначительный эффект. Единственное, что ускоряет его, — это полное разделение выражения на две части. Единственная разница, которую это должно иметь значение, заключается в том, что она уменьшает максимальную глубину стека, используемую Python при вычислении выражения (с 4 до 3).

Это дает нам понять, что эффект связан с глубиной стека, возможно, дополнительный уровень перемещает стек на другую страницу памяти. Если это так, мы должны увидеть, что внесение других изменений, влияющих на стек, изменится (скорее всего, убьет эффект), и на самом деле это то, что мы видим:

$ python3 -m timeit -s "def foo():
   tuple(range(200000)) is tuple(range(200000))" "foo()"
100 loops, best of 3: 10 msec per loop
$ python3 -m timeit -s "def foo():
   tuple(range(200000)) is tuple(range(200000))" "foo()"
100 loops, best of 3: 10 msec per loop
$ python3 -m timeit -s "def foo():
   a = tuple(range(200000));  b = tuple(range(200000)); a is b" "foo()"
100 loops, best of 3: 9.97 msec per loop
$ python3 -m timeit -s "def foo():
   a = tuple(range(200000));  b = tuple(range(200000)); a is b" "foo()"
100 loops, best of 3: 10 msec per loop

Итак, я думаю, что эффект полностью связан с тем, сколько стека Python потребляется в процессе синхронизации. Хотя все равно странно.