为什么 len(<a list object>) 这么慢？答案

【问题标题】：Why is len(<a list object>) so slow?为什么 len(<a list object>) 这么慢？
【发布时间】：2016-02-03 23:06:14
【问题描述】：

我在 ipython 会话中运行以下代码：

# This call is slow, but that is expected. (It loads 3 GB of data.)
In [3]: arc, arc_sub, upls, go = foo_mod.ready_set()

# This call is also slow, as `upls` is huge.
In [4]: upls = list(upls)

# This call is slow in meatspace, but `%timeit` doesn't notice!
In [5]: %timeit -n1 -r1 len(upls)
1 loops, best of 1: 954 ns per loop

%timeit 直接躺在这里。无论有没有%timeit，该命令实际运行需要10 秒以上。然而，这只是第一次；随后对len 的调用很快。

即使time.time() 也唱着类似的曲子：

In [5]: import time

In [6]: s = time.time(); len_ = len(upls); e = time.time()

In [7]: e - s
Out[7]: 7.104873657226562e-05

但在现实世界中，In [6] 真正完成需要秒。我似乎无法捕捉到实际花费的时间！

这个列表没有什么特别的地方，除了它很大：它是一个真正的list；它拥有大约 1/4 亿 bson.ObjectId 对象。（在list() 调用之前，它是一个set 对象；那个调用也很慢，但这是有道理的；list(<set instance>) 是 O(n)，而且我的套装很大。）

编辑重新 GC

如果我在 ready_set 之前运行 gc.set_debug(gc.DEBUG_STATS)，这本身就是一个缓慢的调用，我会看到大量的 GC 周期。这是意料之中的。 gen3 增长：

gc: objects in each generation: 702 701 3289802
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 702 1402 3289802
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 702 2103 3289802

不幸的是，控制台输出使这个运行时间变得非常慢。如果我将gc.set_debug 调用延迟到ready_set 之后，我看不到任何 GC 周期，但gc.get_count() 声称代数很小：

In [6]: gc.get_count()
Out[6]: (43, 1, 193)

In [7]: len(upls)
Out[7]: 125636395

（但是为什么/如何get_count 比列表中的对象少？；它们绝对都是独一无二的，因为它们刚刚经历了set...）在代码中涉及gc 的事实使得lenspeedy 让我相信我正在停下来收集世界。

（版本，以防万一：

Python 2.7.6 (default, Mar 22 2014, 22:59:56)
IPython 3.2.0 -- An enhanced Interactive Python.

)

【问题讨论】：

这很奇怪。同样的事情发生在常规的交互式解释器中吗？
列表知道它们的大小。一旦它在一个列表中，len(thelist) 就是 O(1)
没有。他们只需要跟踪何时插入和删除项目。当你调用 len 时它不会计算它。
不，它不会，几乎任何列表操作都需要知道列表的 len()。
至此，我已经阅读了 Python 2.7 的源代码。 list 本质上知道它的大小。 len 对list 的实现非常简单。 :-/ 不幸的是，它与我看到的行为不符。

标签： python ipython timing

【解决方案1】：

我会根据你的问题对答案进行总结。

正如大家所说（你也指出了），Python 的 list 对象知道它的大小，它知道 returns just the stored number：

static Py_ssize_t
list_length(PyListObject *a)
{
    return Py_SIZE(a);
}

在哪里Py_SIZEis defined：

Py_SIZE(o)

该宏用于访问 Python 对象的 ob_size 成员。它扩展为： (((PyVarObject*)(o))->ob_size)

所以我可以得出结论，它不应该进行任何计算。唯一怀疑的是您尝试转换为列表的对象。但如果你发誓它真的是list，没有任何假对象通过一些懒惰的计算来模拟它的方法——不是的。

所以我假设所有timeit 方法都真正显示了调用len 函数所花费的确切时间。

唯一浪费时间的过程是.. 垃圾收集器。在您的测量结束时，它发现没有人使用如此大的数据并开始释放内存。当然，这需要几秒钟。

【讨论】：