为什么复制经过改组的列表要慢得多？

89

复制一份随机播放的range(10**6)列表十次需要我大约0.18秒：（这五次运行）

0.175597017661
0.173731403198
0.178601711594
0.180330912952
0.180811964451

复制未整理的列表十次需要我大约0.05秒：

0.058402235973
0.0505464636856
0.0509734306934
0.0526022752744
0.0513324916184

这是我的测试代码：

from timeit import timeit
import random

a = range(10**6)
random.shuffle(a)    # Remove this for the second test.
a = list(a)          # Just an attempt to "normalize" the list.
for _ in range(5):
    print timeit(lambda: list(a), number=10)

我也尝试用复制a[:]，结果相似（即，速度差异很大）

为什么速度差大？我知道并理解著名的速度差异，为什么处理排序数组要比未排序数组快？例如，但是在这里我的处理没有决定。只是盲目地复制列表中的引用，不是吗？

我在Windows 10上使用Python 2.7.12。

编辑：现在也尝试使用Python 3.5.2，结果几乎相同（在0.17秒左右一致改组，在0.05秒左右一致改组）。这是代码：

a = list(range(10**6))
random.shuffle(a)
a = list(a)
for _ in range(5):
    print(timeit(lambda: list(a), number=10))
python  python-internals 
— 斯蒂芬·波希曼（Stefan Pochmann）
source
22
— -vaultah
5
请不要对我大喊，我正试图帮助您！更改顺序后，我大致获得0.25了每个测试的每次迭代。因此，在我的平台上，顺序很重要。
— barak manos
1
@vaultah谢谢，但是我已经读过了，但我不同意。当我在那里看到代码时，我立即想到了int的高速缓存命中/未命中，这也是作者的结论。但是他的代码加上了数字，这就需要查看它们。我的代码没有。我的人只需要复制参考，而不需要通过它们进行访问。
— Stefan Pochmann
2
@vaultah的链接中有完整答案（我知道您现在稍有不同意见）。但是无论如何，我仍然认为我们不应该将python用于低级功能，因此要担心。但是无论如何，这个话题很有趣，谢谢。
— 尼古拉·普罗科皮耶夫（Nikolay Prokopyev），
1
@NikolayProkopyev是的，我并不担心它，只是在做其他事情时注意到了这一点，无法解释它，并且对此感到好奇。我很高兴我问了一个并且现在得到答案:-)
— Stefan Pochmann

Answers:

100

有趣的是，它取决于整数的顺序 首次创建。例如，而不是使用shuffle创建随机序列random.randint：

from timeit import timeit
import random

a = [random.randint(0, 10**6) for _ in range(10**6)]
for _ in range(5):
    print(timeit(lambda: list(a), number=10))

这和复制您的文件一样快list(range(10**6))（第一个也是快速的示例）。

但是，当您随机播放时-整数就不再按照它们最初创建的顺序排列了，这就是它变慢的原因。

一个快速的间奏：

  • 所有Python对象都在堆上，因此每个对象都是一个指针。
  • 复制列表是一项浅层操作。
  • 但是Python使用引用计数，因此当将对象放入新容器时，它的引用计数必须增加（Py_INCREFinlist_slice），因此Python确实需要转到该对象所在的位置。它不能只是复制参考。

因此，当您复制列表时，将获得该列表的每个项目并将其“按原样”放在新列表中。当下一个项目在当前项目之后不久创建时，很有可能（不保证！）将其保存在堆上。

假设每当您的计算机将一个项目加载到缓存中时，它也会同时加载x内存中的项目（缓存位置）。然后，您的计算机可以x+1对同一缓存中的项目执行引用计数递增！

通过改组序列，它仍会加载内存中的下一个项目，但这些不是列表中的下一个项目。因此，如果没有“真正”寻找下一项，它就无法执行参考计数递增。

TL; DR：实际速度取决于复制之前发生的情况：这些项目以什么顺序创建以及列表中的顺序是什么。

您可以通过查看来验证这一点id：

CPython实现细节：这是对象在内存中的地址。

a = list(range(10**6, 10**6+100))
for item in a:
    print(id(item))

仅显示一个简短的摘录：

1496489995888
1496489995920  # +32
1496489995952  # +32
1496489995984  # +32
1496489996016  # +32
1496489996048  # +32
1496489996080  # +32
1496489996112
1496489996144
1496489996176
1496489996208
1496489996240
1496507297840
1496507297872
1496507297904
1496507297936
1496507297968
1496507298000
1496507298032
1496507298064
1496507298096
1496507298128
1496507298160
1496507298192

因此，这些对象实际上“在堆上彼此相邻”。与shuffle他们不是：

import random
a = list(range(10**6, 100+10**6))
random.shuffle(a)
last = None
for item in a:
    if last is not None:
        print('diff', id(item) - id(last))
    last = item

这表明这些在内存中并不是真正相邻的：

diff 736
diff -64
diff -17291008
diff -128
diff 288
diff -224
diff 17292032
diff -1312
diff 1088
diff -17292384
diff 17291072
diff 608
diff -17290848
diff 17289856
diff 928
diff -672
diff 864
diff -17290816
diff -128
diff -96
diff 17291552
diff -192
diff 96
diff -17291904
diff 17291680
diff -1152
diff 896
diff -17290528
diff 17290816
diff -992
diff 448

重要的提示：

我自己还没有想到这一点。大多数信息可以在Ricky Stewart的博客中找到。。

该答案基于Python的“官方” CPython实现。其他实现（Jython，PyPy，IronPython等）的细节可能有所不同。感谢@JörgWMittag 指出这一点。

— 塞弗特
source
6
@augurar复制引用意味着增加对象中的引用计数器（因此不可避免地需要对象访问）
— Leon
1
@StefanPochmann执行复制的功能是list_slice，在453行中，您可以看到Py_INCREF(v);需要访问堆分配对象的调用。
— MSeifert
1
@MSeifert另一个很好的实验是使用a = [0] * 10**7（从10 ** 6起，因为它太不稳定了），它甚至比使用更快a = range(10**7)（约1.25倍）。显然，因为缓存甚至更好。
— Stefan Pochmann，
1
我只是想知道为什么我在使用python 64位的64位计算机上得到32位整数。但是实际上，这对于缓存也有好处：-)甚至[0,1,2,3]*((10**6) // 4)和一样快a = [0] * 10**6。但是，对于0到255之间的整数，会有另一个事实出现：它们被内插，因此使用它们的创建顺序（在脚本内）不再重要了-因为它们是在启动python时创建的。
— MSeifert
2
请注意，在当前存在的四个可用于生产环境的Python实现中，只有一个使用引用计数。因此，此分析实际上仅适用于单个实现。
— —JörgW Mittag
24

当您随机播放列表项时，它们的引用位置会更糟，从而导致更糟的缓存性能。

您可能会认为复制列表只是复制引用，而不是对象，因此它们在堆上的位置无关紧要。但是，复制仍然涉及访问每个对象以修改引用计数。

— 奥古拉尔
source
这可能对我来说是一个更好的答案（至少如果它与MSeifert的“证明”相关联），因为这是我所缺少的，而且非常简洁，但是我认为我会坚持使用MSeifert的，因为我认为可能是这样。对其他人更好。对此也表示支持，谢谢。
— Stefan Pochmann，
还会补充说，类群照片，动植物等中有神秘的逻辑来检测地址模式，并且会在看到模式时开始预取数据。在这种情况下，当数字按顺序排列时，可以开始预取数据（减少缓存丢失）。当然，这种效果是增加了来自本地的点击量的百分比。
— greggo'2
5

正如其他人所解释的那样，它不仅复制了引用，而且还增加了对象内部的引用计数，因此可以访问对象，并且缓存起着作用。

在这里，我只想添加更多实验。与改组和未改组无关（访问一个元素可能会丢失高速缓存，但将以下元素放入高速缓存中以便它们被命中）。但是关于重复元素，由于该元素仍在高速缓存中，因此以后对同一元素的访问可能会命中高速缓存。

测试正常范围：

>>> from timeit import timeit
>>> a = range(10**7)
>>> [timeit(lambda: list(a), number=100) for _ in range(3)]
[5.1915339142808925, 5.1436351868889645, 5.18055115701749]

相同大小但一次又一次重复一个元素的列表会更快，因为它一直都在缓存中：

>>> a = [0] * 10**7
>>> [timeit(lambda: list(a), number=100) for _ in range(3)]
[4.125743135926939, 4.128927210087596, 4.0941229388550795]

它的数字似乎并不重要：

>>> a = [1234567] * 10**7
>>> [timeit(lambda: list(a), number=100) for _ in range(3)]
[4.124106479141709, 4.156590225249886, 4.219242600790949]

有趣的是，当我改为重复相同的两个或四个元素时，它变得更快：

>>> a = [0, 1] * (10**7 / 2)
>>> [timeit(lambda: list(a), number=100) for _ in range(3)]
[3.130586101607932, 3.1001001764957294, 3.1318465707127814]

>>> a = [0, 1, 2, 3] * (10**7 / 4)
>>> [timeit(lambda: list(a), number=100) for _ in range(3)]
[3.096105435911994, 3.127148431279352, 3.132872673690855]

我想有些事情不喜欢同一个计数器一直在增加。也许一些管道失速因为每次增加都必须等待之前增加的结果，但这是一个疯狂的猜测。

无论如何，尝试使用更多的重复元素：

from timeit import timeit
for e in range(26):
    n = 2**e
    a = range(n) * (2**25 / n)
    times = [timeit(lambda: list(a), number=20) for _ in range(3)]
    print '%8d ' % n, '  '.join('%.3f' % t for t in times), ' => ', sum(times) / 3

输出（第一列是不同元素的数量，每个元素我测试三次，然后取平均值）：

       1  2.871  2.828  2.835  =>  2.84446732686
       2  2.144  2.097  2.157  =>  2.13275338734
       4  2.129  2.297  2.247  =>  2.22436720645
       8  2.151  2.174  2.170  =>  2.16477771575
      16  2.164  2.159  2.167  =>  2.16328197911
      32  2.102  2.117  2.154  =>  2.12437970598
      64  2.145  2.133  2.126  =>  2.13462250728
     128  2.135  2.122  2.137  =>  2.13145065221
     256  2.136  2.124  2.140  =>  2.13336283943
     512  2.140  2.188  2.179  =>  2.1688431668
    1024  2.162  2.158  2.167  =>  2.16208440826
    2048  2.207  2.176  2.213  =>  2.19829998424
    4096  2.180  2.196  2.202  =>  2.19291917834
    8192  2.173  2.215  2.188  =>  2.19207065277
   16384  2.258  2.232  2.249  =>  2.24609975704
   32768  2.262  2.251  2.274  =>  2.26239771771
   65536  2.298  2.264  2.246  =>  2.26917420394
  131072  2.285  2.266  2.313  =>  2.28767871168
  262144  2.351  2.333  2.366  =>  2.35030805124
  524288  2.932  2.816  2.834  =>  2.86047313113
 1048576  3.312  3.343  3.326  =>  3.32721167007
 2097152  3.461  3.451  3.547  =>  3.48622758473
 4194304  3.479  3.503  3.547  =>  3.50964316455
 8388608  3.733  3.496  3.532  =>  3.58716466865
16777216  3.583  3.522  3.569  =>  3.55790996695
33554432  3.550  3.556  3.512  =>  3.53952594744

因此，从单个（重复）元素的大约2.8秒下降到2、4、8、16 ...个不同元素的大约2.2秒，并保持在大约2.2秒，直到成百上千个。我认为这使用了我的L2缓存（4×256 KB，我有i7-6700）。

然后经过几步，时间最多达到3.5秒。我认为这会混合使用我的L2缓存和我的L3缓存（8 MB），直到“用尽”为止。

最终，它停留在3.5秒左右，因为我的缓存不再对重复的元素有所帮助。

— 斯蒂芬·波希曼（Stefan Pochmann）
source
0

随机播放之前，在堆中分配时，相邻的索引对象在内存中相邻，并且在访问时内存命中率很高；随机播放后，新列表的相邻索引的对象不在内存中。相邻的命中率非常差。

— ws
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.