“in”运算符或 obj.hasOwnProperty(prop) 的 Big O 表示法的效率是多少答案

【问题标题】：What's the efficiency in Big O notation of the "in" operator or obj.hasOwnProperty(prop)“in”运算符或 obj.hasOwnProperty(prop) 的 Big O 表示法的效率是多少
【发布时间】：2011-05-16 00:31:25
【问题描述】：

Mozilla 的网站清楚地描述了hasOwnProperty() 和in 运算符。

但是，它没有提供有关其效率的任何实施细节。

我怀疑他们会是O(1)（恒定时间），但我希望看到任何可能存在的参考或测试。

【问题讨论】：

我认为是hashmap，所以应该是O(1)。
使用某种哈希值才有意义，因为根据定义，属性应该是唯一的，但最好检查一些参考资料，尤其是 IE 如何实现它们。
我会说它可能依赖于实现。我会破解你最喜欢的开源实现的源代码。

标签： javascript performance big-o

【解决方案1】：

把我的 cmets 变成一个答案。

hasOwnProperty() 应该是O(1)，因为它是一个键查找，但它是特定于实现的。

in 肯定会更复杂（尽管如果该属性存在于该对象上，则应该与hasOwnProperty() 相同），因为它沿着原型链向上寻找该属性。这就是为什么在使用for ( in ) 迭代对象属性时通常建议使用hasOwnProperty()。

要找出答案，请检查这些函数的源代码。使用来源，卢克 :)

【讨论】：

"in" 仍然是 O(1)，因为在一组 n 个元素中查找其中 1 个元素的时间将不依赖于其余 n 个元素，并且仍然是恒定的
虽然在查看源代码时绝对是个好建议，但如果有人已经遇到过它，那只是试图偷工减料:)。谢谢。
@haknick 我想你当时回答了你自己的问题:)
hashmap 还取决于散列函数是什么以及它可能发生冲突的频率。如果有很多碰撞，您最终可能会得到 O(log(n)) 到 O(n)，具体取决于碰撞的严重程度。这当然也取决于索引的大小以及重新索引的频率（即从 32 到 64 的索引）。

【解决方案2】：

我的理论是in 应该比hasOwnProperty() 快。 in 是 hasProperty() 的代理（根据标准：http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf -- 参见第 79 页），这是一个在整个语言中广泛使用的内部函数（并且会隐含地进行高度优化）。事实上，测试表明平均而言，in 更快。

链接：http://jsfiddle.net/VhhzR/2/

在 Firefox 中，in 明显更快。在 Chrome 中，in 仅在处理复杂对象时更快（令人费解）。在 Internet Explorer 中，in 再次领先。

希望这对您有所帮助:)

【讨论】：

【解决方案3】：

我不认为它与对象属性查找机制有什么不同，因为它们实际上是做同样的事情，区别在于hasOwnProperty(prop) 只在对象本身中查找，而o.prop 将沿着原型层次结构向下查找。

【讨论】：

感谢您的回答。实际上并没有试图比较两者，而是研究两者的细节。