list()使用的内存比列表推导式稍多。

Question

我在使用list对象时发现一个奇怪的事情，如果使用list()创建list，它会使用更多的内存，而使用列表推导式则不会？ 我正在使用Python 3.5.2

In [1]: import sys
In [2]: a = list(range(100))
In [3]: sys.getsizeof(a)
Out[3]: 1008
In [4]: b = [i for i in range(100)]
In [5]: sys.getsizeof(b)
Out[5]: 912
In [6]: type(a) == type(b)
Out[6]: True
In [7]: a == b
Out[7]: True
In [8]: sys.getsizeof(list(b))
Out[8]: 1008

从文档中可以看出：

有几种方法可以构造列表：

• 使用一对方括号表示空列表：[]
• 使用方括号，用逗号分隔项目：[a]、[a, b, c]
• 使用列表推导式：[x for x in iterable]
• 使用类型构造函数：list() 或 list(iterable)

但似乎使用list()会使用更多的内存。

随着列表变得越来越大，差距也会增加。

为什么会这样呢？

更新 #1

使用 Python 3.6.0b2 进行测试：

Python 3.6.0b2 (default, Oct 11 2016, 11:52:53) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(range(100)))
1008
>>> sys.getsizeof([i for i in range(100)])
912

更新 #2

使用 Python 2.7.12 进行测试：

Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(xrange(100)))
1016
>>> sys.getsizeof([i for i in xrange(100)])
920

- vishes_shell

---

这是一个非常有趣的问题。我可以在Python 3.4.3中重现这个现象。更有趣的是：在Python 2.7.5中，sys.getsizeof(list(range(100)))为1016，getsizeof(range(100))为872，而getsizeof([i for i in range(100)])为920。它们都属于list类型。 - Sven Rusch

有趣的是，这个差异在Python 2.7.10中也存在（尽管实际数字与Python 3不同）。在3.5和3.6b中也存在。 - cdarke

我在使用Python 2.7.6时和@SvenFestersen得到了相同的数字，即使我使用xrange。 - RemcoGerlich

这里可能有一个解释：https://dev59.com/imw05IYBdhLWcg3wcRQj。如果其中一种方法使用`append()`创建列表，可能会存在过度分配内存的情况。我猜想真正澄清这个问题的唯一方法是查看Python源代码。 - Sven Rusch

只多了10%（你实际上没有在任何地方这样说）。我会重新措辞标题为“稍微多一点”。 - smci

Answer 1

我认为你正在看到过度分配模式，这是一个 来源示例。

/* This over-allocates proportional to the list size, making room
 * for additional growth.  The over-allocation is mild, but is
 * enough to give linear-time amortized behavior over a long
 * sequence of appends() in the presence of a poorly-performing
 * system realloc().
 * The growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
 */

new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);

---

打印长度为0-88的列表推导式的大小，您可以看到模式匹配：

# create comprehensions for sizes 0-88
comprehensions = [sys.getsizeof([1 for _ in range(l)]) for l in range(90)]

# only take those that resulted in growth compared to previous length
steps = zip(comprehensions, comprehensions[1:])
growths = [x for x in list(enumerate(steps)) if x[1][0] != x[1][1]]

# print the results:
for growth in growths:
    print(growth)

结果（格式为（列表长度，（旧总大小，新总大小）））：

(0, (64, 96)) 
(4, (96, 128))
(8, (128, 192))
(16, (192, 264))
(25, (264, 344))
(35, (344, 432))
(46, (432, 528))
(58, (528, 640))
(72, (640, 768))
(88, (768, 912))

---

为了提高性能，过度分配是为了允许列表在增长时不必每次都分配更多的内存（更好的分摊性能）。

使用列表推导式与使用list()的区别可能是，列表推导式不能确定生成的列表的大小，但list()可以。这意味着当列表推导式填充列表并使用过度分配时，它将不断增加列表的大小，直到最终填满为止。

可能不会在完成后使用未使用的已分配节点来增加过度分配缓冲区（实际上，在大多数情况下，它不会，那样会破坏过度分配的目的）。

然而，list()可以添加一些缓冲区，无论列表的大小如何，因为它事先知道最终列表的大小。

---

另一个支持证据来自源代码，即我们看到 使用LIST_APPEND的列表推导式，这表明使用了list.resize，进而表明在不知道会填充多少的情况下消耗了预分配缓冲区。这与您所看到的行为一致。

---

总之，list() 会根据列表大小预先分配更多的节点。

>>> sys.getsizeof(list([1,2,3]))
60
>>> sys.getsizeof(list([1,2,3,4]))
64

列表推导式不知道列表大小，因此在增长时使用追加操作，消耗预分配的缓冲区：

# one item before filling pre-allocation buffer completely
>>> sys.getsizeof([i for i in [1,2,3]]) 
52
# fills pre-allocation buffer completely
# note that size did not change, we still have buffered unused nodes
>>> sys.getsizeof([i for i in [1,2,3,4]]) 
52
# grows pre-allocation buffer
>>> sys.getsizeof([i for i in [1,2,3,4,5]])
68

- Reut Sharabani

---

为什么一个会出现超额分配，而另一个却不会呢？ - cdarke

这段内容关于list.resize。我不太擅长浏览源代码，但如果一个调用了resize而另一个没有调用，这可能解释了它们之间的差异。 - Reut Sharabani

这里是Python 3.5.2。尝试使用循环打印从0到35的列表大小。对于列表，我看到64、96、104、112、120、128、136、144、160、192、200、208、216、224、232、240、256、264、272、280、288、296、304、312、328、336、344、352、360、368、376、384、400、408、416；对于推导式，我看到64、96、96、96、96、128、128、128、128、192、192、192、192、192、192、192、192、264、264、264、264、264、264、264、264、264、344、344、344、344、344、344、344、344、344。我本来期望推导式似乎预分配内存的算法会在某些大小上使用更多的RAM。 - tavo

我也有同样的期望。我很快会进一步研究它。好评论。 - Reut Sharabani

实际上，list()可以确定列表的大小，而列表推导式无法做到这一点。这表明列表推导式并不总是会触发列表的"最后"增长。这种说法有一定道理。 - Reut Sharabani

我认为，由于range支持len，列表分配了len +一些预分配空间。有趣的是，当我使用生成器对象作为列表的参数（生成器不支持len）时，我得到的大小模式与列表推导不同：64、96、104、112、120、128、160、160、160、160、160、160、160、224、224、224、224、224、224、224、224、296、296、296、296、296、296、296、296、296、376、376、376、376、376。 - tavo

Answer 2

感谢大家帮助我理解这个很棒的Python。

我不想提出太多的问题（所以我发布了答案），只是想表达和分享我的想法。

正如@ReutSharabani正确指出的：“list()确定列表大小的方式是确定性的”。你可以从这张图中看到它。

当使用append或列表推导式时，总会有某种在达到某个点时扩展边界的情况。而在使用list()时，几乎有相同的边界，但它们是浮动的。

更新

因此，感谢@ReutSharabani，@tavo，@SvenFestersen

总结一下：list()根据列表大小预先分配内存，列表推导式不能做到这一点（它在需要时请求更多内存，如.append()）。这就是为什么list()存储更多内存的原因。

另外一张图表，显示了list()预分配内存。所以绿线显示使用list(range(830))逐个添加元素，一段时间内内存不变。

更新2

正如下面的评论中@Barmar所指出的，使用list()比列表推导式更快，因此我针对长度从4**0到4**10的list运行了timeit()，其中number=1000，结果如下：

- vishes_shell

---

红线在蓝线上方的原因是，当list构造函数可以从其参数确定新列表的大小时，它仍将预先分配与最后一个元素刚到达且没有足够空间的情况下相同数量的空间。至少对我来说是这样有意义的。 - tavo

因此，虽然列表推导式使用的内存较少，但由于所有重新调整大小所需的时间，它们可能会显着变慢。这些通常必须将列表骨干复制到新的内存区域。 - Barmar

它会让你的图表更加漂亮。 :) - Barmar

我希望你可以将它们叠加在同一张图上。但是，这表明直到列表变得非常大，您才真正注意到性能影响不大。 - Barmar

@Barmar 叠加不起作用，因为Y轴的测量方式不同（时间和内存），因此不能真正地相互叠加。是的，列表推导很快。 - vishes_shell