优化 JavaScript for 循环
所以我已经知道一段时间了,这
for ( var i=0, len = myArray.length; i < len; i++ ){
}
更有效
for ( var i=0; myArray.length; i++ ){
}
比大型数组 。但想知道前者真正给您带来了多少性能提升?
今天我开始做一些基准测试。我创建了一个数组并向其中放入了 100,000 个数字。
var array = [];
for( var i = 0; i < 100000; i++ )
array.push(i);
然后,我通过对数组中的每个数字执行 console.log 并对过程进行计时来测试上面的两个循环。
console.time('loop');
for( var i = 0; i < array.length; i++ )
console.log(i);
console.timeEnd('loop');
对于第二次测试,
console.time('loop');
for( var i = 0, len = array.length; i < len ;i++ )
console.log(i)
console.timeEnd('loop')
经过几次测试后,我的结果尚无定论。我得到了两个测试用例的高值和低值。所以我的问题是,有什么更好的测试可以明确地表明提前获得长度具有性能优势以及这样做会带来什么样的百分比增益?
So i have known for a while that
for ( var i=0, len = myArray.length; i < len; i++ ){
}
is more efficient than
for ( var i=0; myArray.length; i++ ){
}
for large arrays. But have wondered how much of a performance gain does the former really give you ?
Today i set out to do some benchmarks. I created an array and pushed 100,000 numbers into it.
var array = [];
for( var i = 0; i < 100000; i++ )
array.push(i);
I then tested both loops above by doing a console.log of each of the numbers in the array and timing the process.
console.time('loop');
for( var i = 0; i < array.length; i++ )
console.log(i);
console.timeEnd('loop');
And for the second test
console.time('loop');
for( var i = 0, len = array.length; i < len ;i++ )
console.log(i)
console.timeEnd('loop')
After testing this a few times, my results are inconclusive. I get both high and low numbers for both test cases. So my question is, what's a better test to show unequivocally that getting the length beforehand has performance benefits and what kind of percentage gain is there to doing this ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这是相关的jsperf:
http://jsperf.com/caching-array-length/4
这表明差异可能小得惊人。
Here is a relevant jsperf:
http://jsperf.com/caching-array-length/4
which shows that the difference can be surprisingly little.
在这种情况下,没有任何区别。访问数组的
length
属性是一个非常快速的操作,因为每次数组更改时它都会更新,因此您只是检索一个数字。但是,如果您要循环访问通过
document.querySelectorAll
获取的某些元素,那么缓存结果可能是个好主意,因为对querySelectorAll
的调用可能会很昂贵,并且如果结果不会改变,您不想每次迭代都运行它。In this case, it doesn't make any difference. Accessing the
length
property of an array is a very quick operation since it is updated every time the array changes, and thus you're just retrieving a number.If, however, you were looping through say some elements that you got through
document.querySelectorAll
, then it might be a good idea to cache the results, because the call toquerySelectorAll
can be expensive, and you don't want to run it every iteration if the results won't change.从理论上讲,您的两个示例之间的速度实际上不应该有任何差异。
第一个示例运行速度更快的想法来自像 php 这样的语言,其中等效项是“$i < sizeof($array)”,因为 sizeof 在循环的每次迭代中都有数组长度的计数。但与 PHP 不同的是,JavaScript 已经知道其数组的长度,因此您几乎只需直接读取数字即可。
结果是,在 JavaScript 中,读取“arrlen”和“somearray.length”之间的唯一区别是指针指向的位置,因此速度几乎相同。
也就是说,从 Joseph 发布的基准来看,幕后处理方式显然不是那么简单。在 chrome 15 inline 的情况下实际上似乎更快,而在较旧的版本中它有点慢? 0.0
Theoretically there shouldn't actually be any difference in speed between your two examples.
The idea that the first example will run faster come from languages like php where the equivalent would be "$i < sizeof($array)" since sizeof has the count the length of the array on every iteration of the loop. Unlike PHP though, JavaScript already knows how long its arrays are, so your pretty much just reading the number directly.
The result is that in JavaScripts case the only difference between reading "arrlen" and "somearray.length" is where the pointer is pointing, so the speed will be pretty much identical.
That said, by the looks of the benchmarks Joseph posted, how this is being handled under the hood is obviously not so straight forward. In the case of chrome 15 inline actually seems to be faster, while in the older few its a little bit slower? o.0