Почему цепные выражения операторов медленнее, чем их расширенный эквивалент?
В python можно связать операторов таким образом:
a op b op c
Что оценивается
a op b and b op c
С той лишь разницей, что b оценивается только один раз (так, что-то более похожее на t = eval(b); a op t and t op c).
Это выгодно с точки зрения, что оно очень читаемо и более кратким, чем эквивалентная версия с явной связью (с использованием and).
Однако... Я заметил, что существует незначительная разница в производительности между закодированными выражениями и эквивалентом, будь то три операнда или 20. Это становится очевидным, когда вы выполняете эти операции.
import timeit
timeit.timeit("a <= b <= c", setup="a,b,c=1,2,3")
0.1086414959972899
timeit.timeit("a <= b and b <= c", setup="a,b,c=1,2,3")
0.09434155100097996
А также,
timeit.timeit("a <= b <= c <= d <= e <= f", setup="a,b,c,d,e,f=1,2,3,4,5,6")
0.2151330839988077
timeit.timeit("a <= b and b <= c and c <= d and d <= e and e <= f", setup="a,b,c,d,e,f=1,2,3,4,5,6")
0.19196406500122976
Примечание. Все тесты проводились с помощью Python-3.4.
Изучив байтовый код для обоих выражений, я заметил, что один выполняет значительно больше (фактически, еще 4) операции, чем другие.
import dis
dis.dis("a <= b <= c")
1 0 LOAD_NAME 0 (a)
3 LOAD_NAME 1 (b)
6 DUP_TOP
7 ROT_THREE
8 COMPARE_OP 1 (<=)
11 JUMP_IF_FALSE_OR_POP 21
14 LOAD_NAME 2 (c)
17 COMPARE_OP 1 (<=)
20 RETURN_VALUE
>> 21 ROT_TWO
22 POP_TOP
23 RETURN_VALUE
Сравните это с,
dis.dis("a <= b and b <= c")
1 0 LOAD_NAME 0 (a)
3 LOAD_NAME 1 (b)
6 COMPARE_OP 1 (<=)
9 JUMP_IF_FALSE_OR_POP 21
12 LOAD_NAME 1 (b)
15 LOAD_NAME 2 (c)
18 COMPARE_OP 1 (<=)
>> 21 RETURN_VALUE
Я не знаком с чтением байтового кода, но первый фрагмент кода определенно выполняет больше операций на уровне байтового кода, чем второй.
Вот как я это интерпретировал. В первом случае переменные переносятся на какой-то стек и последовательно отображаются для сравнения. Все переменные отображаются только один раз. Во втором случае нет стека, но по крайней мере (N - 2) операндов приходится загружать в память дважды для сравнения. Похоже, что операция пополнения стека более дорогая, чем загрузка (N - 2) переменных дважды для сравнения, учитывая разницу в скорости.
Вкратце, я пытаюсь понять, почему одна операция всегда медленнее, чем другая, с помощью постоянного фактора. Правильно ли моя гипотеза? Или есть что-то еще для внутренних компонентов python, которых я пропускаю?
Дополнительные критерии:
| System | a <= b <= c | a <= b and b <= c | a <= b <= ... <= e <= f | a <= b and ... and e <= f | Credit |
|--------|---------------------|---------------------|-------------------------|---------------------------|----------------|
| 3.4 | 0.1086414959972899 | 0.09434155100097996 | 0.2151330839988077 | 0.19196406500122976 | @cᴏʟᴅsᴘᴇᴇᴅ |
| 3.6.2 | 0.06788300536572933 | 0.059271858073771 | 0.1505890181288123 | 0.12044331897050142 | @Bailey Parker |
| 2.7.10 | 0.05009198188781738 | 0.04472208023071289 | 0.11113405227661133 | 0.09062719345092773 | @Bailey Parker |
Ответы
Ответ 1
В CPuton на основе стека на основе исполнения байт-кода, сохранение дополнительной ссылки на b для прикованного сравнения не является бесплатным. Это на уровне "серьезно, не беспокойтесь об этом" дешево, но это не буквально бесплатно, и вы сравниваете его со слегка более дешевой операцией по загрузке локальной переменной.
Код операции COMPARE_OP удаляет объекты, которые он сравнивает со стеком, поэтому для сопоставленного сравнения Python должен создать другую ссылку на b (DUP_TOP) и засунуть в два стека два стека (ROT_THREE), чтобы избавиться от него.
В a <= b and b <= c вместо вышеупомянутого перетасования ссылок Python просто копирует другую ссылку на b из массива fastlocals фрейма fastlocals. Это включает в себя меньшее перетаскивание указателя и еще меньшее отклонение от цикла оценки байт-кода, поэтому оно немного дешевле.
