【问题标题】:Why is "for ... in ..." MASSIVELY slower than "list.index()"?为什么“for ... in ...”比“list.index()”慢得多?
【发布时间】:2018-09-13 08:17:56
【问题描述】:

比较列表中搜索算法的执行时间,我得出一个结果,list.index() 比简单的for in 快得多。根据this,它们都应该是 O(n)。我的测试中有这个结果:

简单的解决方案在 3 秒内通过了大约 350 次测试:

def linear_simple(arr):
    for i in range(len(arr)):
        if arr[i] == #my searched value#:
            return i

索引解决方案在 3 秒内通过了所有 2000 次测试(实际上它甚至在 2 秒内完成):

def linear_index(arr):
    return arr.index( #my searched value# )

所有测试数组都是随机生成的。进行了多次测试,结果相似。

这意味着index() 大约快 9 倍。为什么? index() 不是像for in 这样简单地在列表上迭代吗?

【问题讨论】:

  • list.index 在 C 中实现和优化
  • Big-O 表示法是衡量复杂性(执行时间或空间使用如何根据输入大小而增长)的衡量标准,而不是有效执行时间的衡量标准,因此两个算法是 O(n) 的事实并不'这并不意味着它们将花费相同的时间来执行相同的输入集。
  • @brunodesthuilliers 是的,我知道这一点。但我很少看到在相同时间复杂度内执行时间相差 9 倍。

标签: python list search


【解决方案1】:

正如 Chris_Rands 所说,list.index 是用 C 实现的。由于它是编译而不是解释的,因此代码运行得更快。

无论如何,您可以稍微优化一下代码:

def linear_simple(arr, value):
    for i, e in enumerate(arr):
        if e == value:
            return i

这段代码在我的电脑上运行得更快(但不如 list.index 快)

【讨论】:

  • Python 被编译为由 VM 执行的字节码,它不是“解释”的(或者您是否也将 Java 描述为“解释”?)。
  • @brunodesthuilliers 不是都先编译然后编译/解释,基于探查器?另外我认为他是说python是编译的而不是解释的
  • 不不,我是说 python 是被解释的并且肯定它比这更复杂一些。使用 CPython en.wikipedia.org/wiki/CPython 字节码被解释,而 CPython 是实际的参考。无论如何,如果python没有编译成机器指令(在执行之前),它会比优化和编译的C函数慢。
  • @CorentinLimier 如果你走这条路,“机器代码”也会被处理器“解释”。问题不是“编译与解释”,而是编译成什么,由什么解释,以及可以在途中应用哪些优化(在 CPython 实际执行的纯 Python 代码的情况下几乎没有,但这是另一个问题)。我不得不再问一次:你会写“Java 很慢,因为它是被解释的”吗?
  • 我认为这是反讽
猜你喜欢
  • 2020-11-22
  • 1970-01-01
  • 2022-06-12
  • 1970-01-01
  • 2019-09-29
  • 1970-01-01
  • 2014-01-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多