__可以通过考虑
.操作员完成工作所需的时间来解释 某些 性能差异：
>>> x = 'foobar'>>> y = 'foo'>>> sw = x.startswith>>> %timeit x.startswith(y)1000000 loops, best of 3: 316 ns per loop>>> %timeit sw(y)1000000 loops, best of 3: 267 ns per loop>>> %timeit x[:3] == y10000000 loops, best of 3: 151 ns per loop
差的另一部分可以通过以下事实来解释
startswith是一个 函数 ，和甚至无操作函数调用需要一点时间：
>>> def f():... pass... >>> %timeit f()10000000 loops, best of 3: 105 ns per loop
这不能 完全 解释差异，因为使用切片的版本会
len调用函数，并且速度仍然更快（与
sw(y)267 ns相比）：
>>> %timeit x[:len(y)] == y1000000 loops, best of 3: 213 ns per loop
我唯一的猜测是，Python可能会针对内置函数优化查找时间，或者对
len调用进行了大幅优化（这可能是事实）。可以使用自定义
len功能进行测试。也许这是LastCoder识别出的差异所在。
startswith比切片更复杂…
2924 result = _string_tailmatch(self,2925 PyTuple_GET_ITEM(subobj, i),2926 start, end, -1);
在干草堆开始时，这不是一个简单的字符比较循环。我们正在寻找一个遍历向量/元组（subobj）并_string_tailmatch在其上调用另一个函数（）的for循环。多个函数调用在堆栈，参数完整性检查等方面都有开销。
startswith是库函数，而切片似乎是内置在语言中的。
2919 if (!stringlib_parse_args_finds("startswith", args, &subobj, &start, &end))2920 return NULL;
