Ответ 1
Вы тестируете слишком маленький вход; в то время как понимание словаря не имеет такого же преимущества в производительности по сравнению с циклом for по сравнению со списком, что и для реалистичных размеров проблем, которые он может и выполняет for циклов, особенно при таргетинге на глобальное имя.
Ваш вход состоит всего из трех пар ключ-значение. Тестирование с 1000 элементами вместо этого, мы видим, что тайминги очень близки:
>>> import timeit
>>> from random import choice, randint; from string import ascii_lowercase as letters
>>> looped = '''\
... b = {}
... for i,j in a.items():
... b[j]=i
... '''
>>> dictcomp = '''b = {v: k for k, v in a.items()}'''
>>> def rs(): return ''.join([choice(letters) for _ in range(randint(3, 15))])
...
>>> a = {rs(): rs() for _ in range(1000)}
>>> len(a)
1000
>>> count, total = timeit.Timer(looped, 'from __main__ import a').autorange()
>>> (total / count) * 1000000 # microseconds per run
66.62004760000855
>>> count, total = timeit.Timer(dictcomp, 'from __main__ import a').autorange()
>>> (total / count) * 1000000 # microseconds per run
64.5464928005822
Разница в том, что dict comp быстрее, но только в этом масштабе. В 100 раз больше пар ключ-значение разница немного больше:
>>> a = {rs(): rs() for _ in range(100000)}
>>> len(a)
98476
>>> count, total = timeit.Timer(looped, 'from __main__ import a').autorange()
>>> total / count * 1000 # milliseconds, different scale!
15.48140200029593
>>> count, total = timeit.Timer(dictcomp, 'from __main__ import a').autorange()
>>> total / count * 1000 # milliseconds, different scale!
13.674790799996117
что не так уж важно, если вы рассмотрите как обработанные пары ключей-ключей почти 100k. Тем не менее, цикл for явно медленнее.
Итак, почему разница в скорости с тремя элементами? Потому что понимание (словарь, набор, понимание списка или выражение генератора) находится под капотом, реализованным как новая функция, и вызов этой функции имеет базовую стоимость, которую простой цикл не должен оплачивать.
Здесь разборка для байт-кода для обеих альтернатив; обратите внимание на MAKE_FUNCTION операций MAKE_FUNCTION и CALL_FUNCTION в байт-коде верхнего уровня для понимания dict, есть отдельный раздел для того, что делает эта функция, и между этими двумя подходами существует очень мало различий:
>>> import dis
>>> dis.dis(looped)
1 0 BUILD_MAP 0
2 STORE_NAME 0 (b)
2 4 SETUP_LOOP 28 (to 34)
6 LOAD_NAME 1 (a)
8 LOAD_METHOD 2 (items)
10 CALL_METHOD 0
12 GET_ITER
>> 14 FOR_ITER 16 (to 32)
16 UNPACK_SEQUENCE 2
18 STORE_NAME 3 (i)
20 STORE_NAME 4 (j)
3 22 LOAD_NAME 3 (i)
24 LOAD_NAME 0 (b)
26 LOAD_NAME 4 (j)
28 STORE_SUBSCR
30 JUMP_ABSOLUTE 14
>> 32 POP_BLOCK
>> 34 LOAD_CONST 0 (None)
36 RETURN_VALUE
>>> dis.dis(dictcomp)
1 0 LOAD_CONST 0 (<code object <dictcomp> at 0x11d6ade40, file "<dis>", line 1>)
2 LOAD_CONST 1 ('<dictcomp>')
4 MAKE_FUNCTION 0
6 LOAD_NAME 0 (a)
8 LOAD_METHOD 1 (items)
10 CALL_METHOD 0
12 GET_ITER
14 CALL_FUNCTION 1
16 STORE_NAME 2 (b)
18 LOAD_CONST 2 (None)
20 RETURN_VALUE
Disassembly of <code object <dictcomp> at 0x11d6ade40, file "<dis>", line 1>:
1 0 BUILD_MAP 0
2 LOAD_FAST 0 (.0)
>> 4 FOR_ITER 14 (to 20)
6 UNPACK_SEQUENCE 2
8 STORE_FAST 1 (k)
10 STORE_FAST 2 (v)
12 LOAD_FAST 1 (k)
14 LOAD_FAST 2 (v)
16 MAP_ADD 2
18 JUMP_ABSOLUTE 4
>> 20 RETURN_VALUE
Материальные отличия: петлевой код использует LOAD_NAME для b каждой итерации, и STORE_SUBSCR хранить пару ключ-значение в Словаре загружена. MAP_ADD словаря использует MAP_ADD для достижения того же, что и STORE_SUBSCR но не обязательно каждый раз загружать это имя b.
Но только с 3 итерациями MAKE_FUNCTION/CALL_FUNCTION которую нужно выполнить для понимания dict, - это реальное сопротивление производительности:
>>> make_and_call = '(lambda i: None)(None)'
>>> dis.dis(make_and_call)
1 0 LOAD_CONST 0 (<code object <lambda> at 0x11d6ab270, file "<dis>", line 1>)
2 LOAD_CONST 1 ('<lambda>')
4 MAKE_FUNCTION 0
6 LOAD_CONST 2 (None)
8 CALL_FUNCTION 1
10 RETURN_VALUE
Disassembly of <code object <lambda> at 0x11d6ab270, file "<dis>", line 1>:
1 0 LOAD_CONST 0 (None)
2 RETURN_VALUE
>>> count, total = timeit.Timer(make_and_call).autorange()
>>> total / count * 1000000
0.12945385499915574
Более 0,1 мкс, чтобы создать объект функции с одним аргументом и вызвать его (с дополнительным LOAD_CONST для значения None мы передаем)! И это касается разницы между таймингами цикла и понимания для трех пар ключ-значение.
Вы можете уподобить этому удивлению, что человек с лопатой может вырыть маленькое отверстие быстрее, чем экскаватор. Экскаватор-погрузчик, безусловно, может быстро копаться, но человек с лопатой может начать работу быстрее, если вам нужно завести экскаватор и начать движение вперёд!
Помимо нескольких пар ключ-значение (выкапывание большего отверстия), функция create and call cost исчезает в ничто. На этом этапе понимание dict и явный цикл в основном делают то же самое:
- возьмите следующую пару ключ-значение, поп-те в стеке
- вызовите
dict.__setitem__hook через операцию байт-кода с двумя верхними элементами в стеке (STORE_SUBSCRилиMAP_ADD. Это не считается "вызовом функции", поскольку все это внутренне обрабатывается в цикле интерпретатора.
Это отличается от понимания списка, где в версии с обычным циклом необходимо использовать list.append(), включающий поиск атрибута, и вызов функции для каждой итерации цикла. Преимущество скорости распознавания списка зависит от этой разницы; см. описание списка Python
То, что добавляет диктофон, заключается в том, что имя целевого словаря нужно искать только один раз, связывая b с конечным объектом словаря. Если целевой словарь является глобальным, а не локальной переменной, понимание выигрывает, руки вниз:
>>> a = {rs(): rs() for _ in range(1000)}
>>> len(a)
1000
>>> namespace = {}
>>> count, total = timeit.Timer(looped, 'from __main__ import a; global b', globals=namespace).autorange()
>>> (total / count) * 1000000
76.72348440100905
>>> count, total = timeit.Timer(dictcomp, 'from __main__ import a; global b', globals=namespace).autorange()
>>> (total / count) * 1000000
64.72114819916897
>>> len(namespace['b'])
1000
Так что просто используйте понимание диктата. Разница с <30 элементами для обработки слишком мала, чтобы заботиться о них, и в тот момент, когда вы генерируете глобальное или имеете больше предметов, понимание dict все равно выигрывает.