列表理解和长字符串上没有lambda的映射

Question

$ python -m timeit -s'tes = "987kkv45kk321"*100' 'a = [list(i) for i in tes.split("kk")]'
10000 loops, best of 3: 79.4 usec per loop

$ python -m timeit -s'tes = "987kkv45kk321"*100' 'b = list(map(list, tes.split("kk")))'
10000 loops, best of 3: 66.9 usec per loop

$ python -m timeit -s'tes = "987kkv45kk321"*10' 'a = [list(i) for i in tes.split("kk")]'
100000 loops, best of 3: 8.34 usec per loop

$ python -m timeit -s'tes = "987kkv45kk321"*10' 'b = list(map(list, tes.split("kk")))'
100000 loops, best of 3: 7.38 usec per loop

$ python -m timeit -s'tes = "987kkv45kk321"' 'a = [list(i) for i in tes.split("kk")]'
1000000 loops, best of 3: 1.51 usec per loop

$ python -m timeit -s'tes = "987kkv45kk321"' 'b = list(map(list, tes.split("kk")))'
1000000 loops, best of 3: 1.63 usec per loop

我尝试使用timeit并想知道为什么使用list comprehension从string.split（）创建列表列表对于较短的字符串更快，但对于更长的字符串则更慢。

Answer 1

这种时机基本没用。

您获得的时间框架以微秒为单位 - 您只需在每次交互中创建数十个不同的单字符长元素列表。基本上是线性类型，因为您创建的对象数量与字符串长度成正比。这没什么好惊讶的。

Answer 2

map的固定设置成本高于listcomp解决方案的设置成本。但map的每件商品成本较低。因此，对于短输入，map在固定设置成本中支付的费用高于每项目成本所节省的费用（因为项目很少）。当商品数量增加时，map的固定设置成本不会发生变化，但每件商品的节省量会因更多商品而增加，因此map会慢慢提前。

map保存的内容：

1. 仅查找list一次（listcomp必须在每次循环检查嵌套和全局范围后在内置命名空间中查找它，因为它无法保证list isn' t从循环覆盖到循环）
2. 每个项目不执行Python字节码（因为映射函数也是C级别），因此解释器根本不涉及，减少了热C级代码的数量

map失去对map的实际调用（C内置函数运行速度快，但调用速度相对较慢，特别是如果它们采用可变长度参数），以及创建和清理map对象的位置（listcomp闭包是在前面编译的）。但正如我上面提到的，这些都与输入的大小无关，因此如果映射函数是C内置函数，则可以快速弥补它。