python中的字典理解太全面了答案

【问题标题】：Dictionary comprehensions in python are too comprehensivepython中的字典理解太全面了
【发布时间】：2015-07-15 00:57:41
【问题描述】：

使用python2.7发现了一个奇怪的时间执行案例：

data = dict( zip( a[0].split( ':' ), a[1].split( ':' ) ) )

data = { name: value for name, value in zip(a[0].split( ':' ), a[1].split( ':' )) }

这两个调用对我来说似乎完全一样，但是，我发现字典理解版本快了大约 4% - 不是太多，但非常稳定。

这是真的吗？如果是，为什么？还是只是我的想象？

【问题讨论】：

那么这里有多少项？查找全局名称 dict() 也需要时间，如果 zip() 结果中只有 2 项可能超过字典理解中的循环成本。
换句话说，不知道你测试了多少项目是毫无意义的。如果您真的想比较，请坚持使用固定的已知输入，而不是使用 zip() 和 str.split()。
您的生成器只产生一次值，但 timeit 测试运行 1000 次。生成器第一次生成键值对时，会生成其余的测试空字典。
我正在恢复您的编辑；以后，请提出新问题，而不是用新问题更新您现有的帖子。
@MartijnPieters ，是的，你的问题是对的，对不起。

标签： python performance dictionary dictionary-comprehension

【解决方案1】：

您的输入样本太小。查找全局名称 dict() 比仅运行 dict 理解需要更多时间（后者不需要名称查找），但如果您针对大量键值对 @987654322 进行测试@ 获胜，因为循环完全在 C 中完成。

针对大量键值对测试差异，并将测试减少到仅dict() 调用或字典理解（执行zip() 和str.split() 调用两种情况都只有一次，可以忽略）：

>>> from timeit import timeit
>>> import random
>>> from string import ascii_lowercase
>>> kv_pairs = [(''.join(random.sample(ascii_lowercase, random.randint(10, 20))), ''.join(random.sample(ascii_lowercase, random.randint(10, 20))))
...             for _ in xrange(10000)]
>>> len(dict(kv_pairs))  # the random keys happen to be all unique.
10000
>>> timeit('{k: v for k, v in kv_pairs}', 'from __main__ import kv_pairs', number=1000)
1.3174479007720947
>>> timeit('dict(kv_pairs)', 'from __main__ import kv_pairs', number=1000)
0.6737580299377441
>>> timeit('{k: v for k, v in kv_pairs}', 'from __main__ import kv_pairs; kv_pairs = kv_pairs[:3]')
0.511167049407959
>>> timeit('dict(kv_pairs)', 'from __main__ import kv_pairs; kv_pairs = kv_pairs[:3]')
0.6696300506591797

因此，对于 10k 键值对（前两次计时测试），dict() 的速度是两倍，对于仅 3 对（后两次计时），dict 理解获胜。

反编译字节码就知道为什么了；字典理解使用嵌套代码对象来实现实际的字典构建：

>>> import dis
>>> dis.dis(compile('{k: v for k, v in kv_pairs}', '', 'exec'))
  1           0 LOAD_CONST               0 (<code object <dictcomp> at 0x102ef69b0, file "", line 1>)
              3 MAKE_FUNCTION            0
              6 LOAD_NAME                0 (kv_pairs)
              9 GET_ITER            
             10 CALL_FUNCTION            1
             13 POP_TOP             
             14 LOAD_CONST               1 (None)
             17 RETURN_VALUE        
>>> dis.dis(compile('{k: v for k, v in kv_pairs}', '', 'exec').co_consts[0])
  1           0 BUILD_MAP                0
              3 LOAD_FAST                0 (.0)
        >>    6 FOR_ITER                21 (to 30)
              9 UNPACK_SEQUENCE          2
             12 STORE_FAST               1 (k)
             15 STORE_FAST               2 (v)
             18 LOAD_FAST                2 (v)
             21 LOAD_FAST                1 (k)
             24 MAP_ADD                  2
             27 JUMP_ABSOLUTE            6
        >>   30 RETURN_VALUE        
>>> dis.dis(compile('dict(kv_pairs)', '', 'exec'))
  1           0 LOAD_NAME                0 (dict)
              3 LOAD_NAME                1 (kv_pairs)
              6 CALL_FUNCTION            1
              9 POP_TOP             
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

通过使用非常小的样本，您为dict 赋予了太多权重的LOAD_NAME 步骤； dict 理解涉及更多的字节码，每次迭代都执行。

【讨论】：

co_consts[0] 包含什么？一个代码对象，但它来自哪里？是否对应上面的MAKE_FUNCTION？
@JeromeJ：字典推导（以及生成器表达式和集合推导，在 Python 3 中，列表推导）有自己的范围。通过执行它们的字节码作为函数来实现的引擎盖下；第一次反编译显示LOAD_CONST 在索引 0 处加载常量并从中创建一个函数对象 (MAKE_FUNCTION)，然后使用 kv_pairs 作为传入的可迭代对象调用它。在由 @987654336 创建的代码对象上@call 你可以在co_consts元组中找到编译器创建的所有常量。
你说的很对，我的输入量真的很小，每个a[i]里大概有几条。我试图将它增加到 10-15 个元素，并且 dict 毫无疑问已经赢得了胜利。实际上，我不认为 dict 理解与其代码中的 dict() 调用有很大不同。你知道吗，在 python3 中，dict() 是否仍然比 dict 理解更快？
@DmitriiBorisevich：是的，对于已经生成的键值对，在 Python 3 中仍然更快。当您需要对生成的每个键和/或值使用表达式时，请使用字典推导式。