【问题标题】:Why are .call and .apply slower than a direct function call in JavaScript?为什么 .call 和 .apply 比 JavaScript 中的直接函数调用慢?
【发布时间】:2012-01-01 08:06:24
【问题描述】:

我很好奇these jsperf results。它们似乎证明了直接函数调用比使用.call 或.apply 调用的相同函数要快得多。 (.call 和 .apply 之间的差异更让我惊讶。)你能解释一下这些结果吗?

更新:Here is a jsperf 有人离开了测试 .apply 没有第二个数组实例化。

【问题讨论】:

  • 好吧,一方面,至少还有一个函数调用(对“.call()”或“.apply()”的调用)...
  • ...事实上,通过“.call()”或“.apply()”的速度大约是您预期的一半执行两个函数调用,而不是一个。
  • .apply 较慢,因为您也在构造一个数组。
  • @Pointy 是一个不错的经验解释,除了 according to Yehuda Katz、function.call() 和 obj.func() 应该与 [[Call]] 的相同内部调用脱糖。所以无论哪种方式都应该只有一个电话。
  • 在iPad中,apply和call的表现是一样的。

标签: javascript performance


【解决方案1】:

我猜原因可能取决于您在哪个解释器上运行代码,但似乎普通函数调用更快,因为解释器可以使用内联缓存来访问属性。

您可以查看here了解更多信息。

【讨论】:

  • 如果你运行这个 [test][1] 你会注意到 .call 和普通调用一样快,可能是因为当数组包含不同类型的值时,解释器在类型推断上遇到困难...
  • “解释器可以使用内联缓存访问属性”是什么意思:什么属性?
  • 我的意思是对象属性。当你在 javascript 中调用 obj.myProp 时,解释器需要遍历对象中的所有属性来检查哪个属性对应于“myProp”。一种可能的优化方法是“记住”该属性在对象属性列表中的索引,并在下一次函数调用时直接跳转到该属性。
  • 是的,现在好像坏了。我依稀记得它指向大卫曼德林的演讲。从链接名称中,您可能可以在这里找到相同的材料:conferences.oreilly.com/velocity/velocity2011/public/schedule/…(此链接的 pdf 文件无论如何都与答案相关)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-11-03
  • 2014-12-19
  • 2011-12-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-22
相关资源
最近更新 更多