内存中列表的大小

Question

我只是尝试了内存中python数据结构的大小。我写了以下代码片段：import syslst1=[]lst1.append(1)lst2=[1]print(sys.getsizeof(lst1), sys.getsizeof(lst2))我在以下配置上测试了代码：Windows 7 64位，Python3.1：输出为：52 40所以lst1有52个字节，lst2有40个字节。使用Python3.2的Ubuntu 11.4 32bit：输出为 48 32Ubuntu 11.4 32位Python2.7： 48 36谁能向我解释为什么两个大小都不同，尽管它们都是包含1的列表？在getsizeof函数的python文档中，我发现了以下内容：...adds an additional garbage collector overhead if the object is managed by the garbage collector.在我的小示例中可能是这种情况吗？

Answer 1

抱歉，以前的评论有点简短。

发生的事情是您正在查看列表的分配方式（我想也许您只是想看看有多大的东西-在这种情况下，请使用sys.getsizeof()）

将某些内容添加到列表时，可能会发生以下两种情况之一：

多余的物品适合剩余空间

需要额外的空间，因此将创建一个新列表，并复制内容，并添加其他内容。

由于（2）昂贵（复制事物，甚至指针，花费的时间与要复制的事物的数量成正比，因此随着列表的增加而增加），我们不希望这样做。因此，我们添加了一个完整的块，而不是仅添加更多的空间。通常，添加量的大小类似于已使用的数量-这样一来，数学计算得出，分配给许多用途的平均内存分配成本仅与列表大小成比例。

因此您所看到的与此行为有关。我不知道确切的详细信息，但是如果[]或[1]（或两者）是特殊情况，即仅分配足够的内存（在这些常见情况下可以节省内存），然后追加“获取一个” ，我不会感到惊讶。上面介绍的“新块”中添加了更多内容。

但是我不知道确切的细节-这只是动态数组的一般工作方式。将对python中列表的确切实现进行微调，以使其最适合典型的python程序。因此，我真正要说的是，您不能相信列表的大小来确切地告诉您其中包含多少-它可能包含额外的空间，并且额外的可用空间量很难判断或预测。

ps的一种很好的替代选择是将列表(value, pointer)成对，其中每个指针都指向下一个元组。这样，尽管使用的总内存更高，但是您可以递增地增加列表。那是一个链表（python使用的更像是向量或动态数组）。

[更新]请参阅Eli的出色答案。他/她解释说，[]和[1]都被完全分配，但是追加到会[]分配额外的块。代码中的注释就是我在上面所说的（这称为“超额分配”，金额与我们所拥有的金额成比例，因此平均（“摊销”）成本与规模成正比）。