list（）比列表理解使用更多的内存

Question 1

因此，我在玩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()它会占用更多内存。

并尽可能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

Question 2

我认为您正在看到过度分配模式，这是来自源的示例：

/* 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)

结果（格式为(list length, (old total size, new total size))）：

(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_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