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

来自docs：

  

列表可以通过多种方式构建：

     

  
• 使用一对方括号表示空列表：[]
  
• 使用方括号，用逗号分隔项目：[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

Answer 1

我认为您看到过度分配模式，这是sample from the source：

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

过度分配是出于性能原因而完成的，允许列表增长而不会在每次增长时分配更多内存（性能更好amortized）。

与使用列表理解不同的一个可能原因是列表推导不能确定地计算生成列表的大小，但list()可以。这意味着理解将不断增加列表，因为它使用过度分配填充它，直到最终填充它。

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

但是，

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

同样来自消息来源的另一个支持证据是，我们看到list comprehensions invoking 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

Answer 2

感谢大家帮助我理解那个令人敬畏的Python。

我不想提出那么大的问题（这就是我发布答案的原因），只是想展示和分享我的想法。

正如@ReutSharabani所指出的那样：“list（）确定性地确定列表大小”。你可以从那张图中看到它。

当你append或使用列表理解时，你总会有某种边界在你到达某个点时延伸。使用list()，您的边界几乎相同，但它们是浮动的。

<强>更新

感谢@ReutSharabani，@tavo，@SvenFestersen

总结：list()预分配内存取决于列表大小，列表理解不能这样做（它在需要时请求更多内存，如.append()）。这就是list()存储更多内存的原因。

另一个图表，显示list()预分配内存。因此，绿线显示list(range(830))逐个元素追加，一段时间内存不变。

更新2

正如@Barmar在下面的评论中指出的那样，list()必须比列表理解更快，所以我使用timeit() number=1000来list 4**0来自4**10 }到{{1}}，结果是