首先,我应该说这个答案是在 2011 年写的,这些东西随着时间的推移而改变(随着浏览器解释器优化越来越多的东西)所以如果你真的想知道世界的当前状态,你必须在当前浏览器上运行测试.
在任何版本的 IE 上运行您自己的 jsperf 测试。在那里您会看到这两种方法或许多其他旧浏览器之间的一致差异。你显然只在 Chrome 上运行它,它是如此之快,如此优化,以至于这两种方法之间的差异可以忽略不计。在 IE9 上(可能比 IE7 和 IE8 好得多),预缓存长度的方法快了 31%。
为这个问题设计的 jsperf 测试给出了这个问题的定量结果。在像这样的问题中,应该去 jsperf 看看真正的区别是什么,而不是那么多的猜测。
它显示了我尝试过的浏览器的差异,从几乎没有差异到相当大的差异取决于浏览器。 在 Chrome 中,几乎没有区别。在 IE9 中,首先存储长度几乎快了 50%。
现在,这种速度差异对您的脚本是否重要取决于特定的代码。如果您有一个经常循环的巨大数组,那么在某些浏览器中使用这种形式可能会产生有意义的不同:
for (var i = 0, len = list.length; i < len; i++) {
// do code here
}
在使用某些 DOM 函数返回的实时伪数组时,在稍微不同的测试用例中,速度仍然存在差异,但没有放大(我预计 DOM 伪实时数组的差异会更大,但事实并非如此)。
在实践中,当我认为我的代码部分对速度不敏感和/或数组不大时,我倾向于使用短版本(较少输入),如果我认为我会使用预先缓存长度的较长版本我有意识地考虑速度或数组很大,或者我正在对同一个数组进行大量迭代。
预缓存长度还有其他几个编程原因。如果您将在循环期间将元素添加到数组的末尾,并且您不希望循环遍历那些新添加的元素,那么您将需要预加载长度并且只遍历最初存在的元素.
for (var i = 0, len = list.length; i < len; i++) {
if (list[i] == "whatever") {
list.push("something");
}
}
请记住,浏览器在不断发展并添加越来越多的优化,因此在 2011 年显示出巨大收益的优化可能在未来基本上内置到更现代的浏览器中,因此不再需要手动编码优化。因此,如果您试图针对当今的性能优化某些内容,则必须在当今的浏览器中进行测试,您不能仅仅依赖于您阅读的可能已有几年历史的内容。