Question

令人惊讶的是，我发现startswith慢于in：

In [10]: s="ABCD"*10

In [11]: %timeit s.startswith("XYZ")
1000000 loops, best of 3: 307 ns per loop

In [12]: %timeit "XYZ" in s
10000000 loops, best of 3: 81.7 ns per loop

众所周知，in操作需要搜索整个字符串，而startswith只需要检查前几个字符，因此startswith应该更有效。

当s足够大时，startswith会更快：

In [13]: s="ABCD"*200

In [14]: %timeit s.startswith("XYZ")
1000000 loops, best of 3: 306 ns per loop

In [15]: %timeit "XYZ" in s
1000000 loops, best of 3: 666 ns per loop

所以看起来调用startswith会有一些开销，当字符串很小时会使它变慢。

而不是我试图找出startswith电话的开销。

首先，我使用f变量来降低点操作的成本 - 正如answer中所述 - 在这里我们可以看到startswith仍然较慢：

In [16]: f=s.startswith

In [17]: %timeit f("XYZ")
1000000 loops, best of 3: 270 ns per loop

此外，我测试了空函数调用的成本：

In [18]: def func(a): pass

In [19]: %timeit func("XYZ")
10000000 loops, best of 3: 106 ns per loop

无论点操作和函数调用的成本如何，startswith的时间约为（270-106）= 164ns，但in操作仅需81.7ns。似乎startswith还有一些开销，那是什么？

按照poke和lvc的建议在startswith和__contains__之间添加测试结果：

In [28]: %timeit s.startswith("XYZ")
1000000 loops, best of 3: 314 ns per loop

In [29]: %timeit s.__contains__("XYZ")
1000000 loops, best of 3: 192 ns per loop

Answer 1

正如评论中已经提到的，如果你使用s.__contains__("XYZ")，你会得到一个更像s.startswith("XYZ")的结果，因为它需要采用相同的路径：成员查找字符串对象，然后是一个函数调用。这通常有些昂贵（当然不足以让你担心）。另一方面，当您执行"XYZ" in s时，解析器会解释运算符并可以快速查看成员对__contains__的访问权限（或者更确切地说是其背后的实现，因为__contains__本身是只是访问实现的一种方式。）

您可以通过查看字节码来了解这一点：

>>> dis.dis('"XYZ" in s')
  1           0 LOAD_CONST               0 ('XYZ')
              3 LOAD_NAME                0 (s)
              6 COMPARE_OP               6 (in)
              9 RETURN_VALUE
>>> dis.dis('s.__contains__("XYZ")')
  1           0 LOAD_NAME                0 (s)
              3 LOAD_ATTR                1 (__contains__)
              6 LOAD_CONST               0 ('XYZ')
              9 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
             12 RETURN_VALUE

因此，将s.__contains__("XYZ")与s.startswith("XYZ")进行比较会产生更相似的结果，但对于示例字符串s，startswith仍然会更慢。

为此，您可以检查两者的实现。有趣的是contains implementation看到它是静态类型的，只是假设参数本身就是一个unicode对象。所以这非常有效。

然而，startswith implementation是一个“动态”Python方法，它要求实现实际解析参数。 startswith还支持一个元组作为参数，这使得该方法的整个启动速度有点慢:(由我缩短，并附有我的评论）：

static PyObject * unicode_startswith(PyObject *self, PyObject *args)
{
    // argument parsing
    PyObject *subobj;
    PyObject *substring;
    Py_ssize_t start = 0;
    Py_ssize_t end = PY_SSIZE_T_MAX;
    int result;
    if (!stringlib_parse_args_finds("startswith", args, &subobj, &start, &end))
        return NULL;

    // tuple handling
    if (PyTuple_Check(subobj)) {}

    // unicode conversion
    substring = PyUnicode_FromObject(subobj);
    if (substring == NULL) {}

    // actual implementation
    result = tailmatch(self, substring, start, end, -1);
    Py_DECREF(substring);
    if (result == -1)
        return NULL;
    return PyBool_FromLong(result);
}

这可能是startswith由于其简单而导致contains快速的字符串变慢的一个重要原因。

Answer 2

这可能是因为str.startswith()的作用超过str.__contains__()，而且因为我认为str.__contains__在C中完全运作，而str.startswith()必须与Python类型进行交互。它的签名是str.startswith(prefix[, start[, end]])，其中prefix可以是要尝试的字符串元组。

为什么字符串的开头慢于？

2 个答案: