«X <y <z» быстрее, чем «x <y и y <z»?

Из этой страницы мы знаем, что:

Связанные сравнения выполняются быстрее, чем использование andоператора. Пишите x < y < zвместо x < y and y < z.

Однако я получил другой результат, проверяя следующие фрагменты кода:

$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y < z"
1000000 loops, best of 3: 0.322 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y and y < z"
1000000 loops, best of 3: 0.22 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y < z"
1000000 loops, best of 3: 0.279 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y and y < z"
1000000 loops, best of 3: 0.215 usec per loop

Похоже, что x < y and y < zбыстрее чем x < y < z. Зачем?

После поиска некоторых сообщений на этом сайте (например, этого ) я знаю, что «оценивается только один раз» - это ключ к успеху x < y < z, однако я все еще не понимаю. Для дальнейшего изучения я разобрал эти две функции, используя dis.dis:

import dis

def chained_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y < z

def and_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y and y < z

dis.dis(chained_compare)
dis.dis(and_compare)

И результат:

## chained_compare ##

  4           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

  5           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

  6          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

  7          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 DUP_TOP
             25 ROT_THREE
             26 COMPARE_OP               0 (<)
             29 JUMP_IF_FALSE_OR_POP    41
             32 LOAD_FAST                2 (z)
             35 COMPARE_OP               0 (<)
             38 JUMP_FORWARD             2 (to 43)
        >>   41 ROT_TWO
             42 POP_TOP
        >>   43 POP_TOP
             44 LOAD_CONST               0 (None)
             47 RETURN_VALUE

## and_compare ##

 10           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

 11           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

 12          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

 13          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 COMPARE_OP               0 (<)
             27 JUMP_IF_FALSE_OR_POP    39
             30 LOAD_FAST                1 (y)
             33 LOAD_FAST                2 (z)
             36 COMPARE_OP               0 (<)
        >>   39 POP_TOP
             40 LOAD_CONST               0 (None)

Кажется, что у x < y and y < zнего меньше скрытых команд, чем у x < y < z. Стоит ли считать x < y and y < zбыстрее, чем x < y < z?

Протестировано с Python 2.7.6 на процессоре Intel (R) Xeon (R) E5640 @ 2,67 ГГц.

Разница в том, что in x < y < z yоценивается только один раз. Это не имеет большого значения, если y - переменная, но имеет значение, когда это вызов функции, для вычисления которого требуется некоторое время.

from time import sleep
def y():
    sleep(.2)
    return 1.3
%timeit 1.2 < y() < 1.8
10 loops, best of 3: 203 ms per loop
%timeit 1.2 < y() and y() < 1.8
1 loops, best of 3: 405 ms per loop

Оптимальный байт-код для обеих функций, которые вы определили, будет

          0 LOAD_CONST               0 (None)
          3 RETURN_VALUE

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

def interesting_compare(y):
    x = 1.1
    z = 1.3
    return x < y < z  # or: x < y and y < z

Опять же, две версии сравнения семантически идентичны, поэтому оптимальный байт-код одинаков для обеих конструкций. Насколько я могу понять, это будет выглядеть так. Я аннотировал каждую строку с содержимым стека до и после каждого кода операции в нотации Forth (верх стека справа, --делится до и после, завершение ?указывает на то, что могло или не могло быть там). Обратите внимание, что RETURN_VALUEотбрасывает все, что осталось в стеке под возвращенным значением.

          0 LOAD_FAST                0 (y)    ;          -- y
          3 DUP_TOP                           ; y        -- y y
          4 LOAD_CONST               0 (1.1)  ; y y      -- y y 1.1
          7 COMPARE_OP               4 (>)    ; y y 1.1  -- y pred
         10 JUMP_IF_FALSE_OR_POP     19       ; y pred   -- y
         13 LOAD_CONST               1 (1.3)  ; y        -- y 1.3
         16 COMPARE_OP               0 (<)    ; y 1.3    -- pred
     >>  19 RETURN_VALUE                      ; y? pred  --

Если реализация языка CPython, PyPy и т. Д. Не генерирует этот байт-код (или его собственную эквивалентную последовательность операций) для обоих вариантов, это демонстрирует низкое качество этого компилятора байт-кода . Получение из последовательностей байт-кода, которые вы разместили выше, является решенной проблемой (я думаю, все, что вам нужно в этом случае, - это сворачивание констант , удаление мертвого кода и лучшее моделирование содержимого стека; обычное устранение подвыражения также было бы дешевым и ценным ), и нет никакого оправдания тому, чтобы не делать этого в современной языковой реализации.

Теперь случается, что все текущие реализации языка имеют некачественные компиляторы байт-кода. Но вы должны игнорировать это при кодировании! Представьте, что компилятор байт-кода хорош, и напишите наиболее читаемый код. В любом случае, вероятно, будет достаточно быстро. Если это не так, сначала поищите алгоритмические улучшения, а затем попробуйте Cython - это обеспечит гораздо больше улучшений при тех же усилиях, чем любые настройки на уровне выражений, которые вы могли бы применить.

Поскольку разница в выводе, похоже, связана с отсутствием оптимизации, я думаю, вам следует игнорировать эту разницу в большинстве случаев - может быть, разница исчезнет. Разница в том, что yоценивать нужно только один раз, и это решается путем дублирования его в стеке, что требует дополнительных POP_TOP- LOAD_FASTхотя решение для использования может быть возможным.

Однако важное различие заключается в том, что во x<y and y<zвтором yслучае следует оценивать дважды, если он x<yоценивается как истинный, это имеет значение, если оценка yзанимает значительное время или имеет побочные эффекты.

В большинстве случаев вам следует использовать, x<y<zхотя он несколько медленнее.

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

x < y < zКонструкция:

1. Яснее и прямее по своему смыслу.
2. Его семантика - это то, что вы ожидаете от «математического значения» сравнения: вычислить x, yи z один раз проверить, выполняется ли все условие. Использование andизменяет семантику путем yмногократной оценки , что может изменить результат .

Поэтому выбирайте одно вместо другого в зависимости от желаемой семантики и, если они эквивалентны, будет ли один более читаемым, чем другой.

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

Но обратите внимание, что этот результат не сохраняется в более общей ситуации, а только в «худшем случае», который вы можете профилировать. Как отмечали другие, если вы измените yчто-то, что займет даже немного больше времени, вы увидите, что результаты меняются, потому что цепная нотация оценивает это только один раз.

Подводя итог:

• Перед выполнением рассмотрите семантику.
• Учитывайте удобочитаемость.
• Не доверяйте микробенчмаркам. Всегда выполняйте профилирование с разными типами параметров, чтобы увидеть, как время функции / выражения ведет себя по отношению к указанным параметрам, и подумайте, как вы планируете его использовать.