我从书中学到,你应该这样写for循环:

for(var i=0, len=arr.length; i < len; i++){
    // blah blah
}

所以arr。每次不计算长度。

其他人说编译器会做一些优化,所以你可以这样写:

for(var i=0; i < arr.length; i++){
    // blah blah
}

我只是想知道在实践中哪种方法是最好的?


当前回答

2014年While回来了

要有逻辑性。

看看这个

for( var index = 0 , length = array.length ; index < length ; index++ ) {

 //do stuff

}

需要创建至少2个变量(index,length) 需要检查索引是否小于长度 需要增加索引 for循环有3个参数

现在告诉我为什么这个要比

var length = array.length;

while( --length ) { //or length--

 //do stuff

}

一个变量 没有检查 指数下降(机器更喜欢这样) While只有一个参数

当Chrome 28显示for循环比while快时,我完全困惑了。 这一定是某种

“嗯,每个人都在使用for循环,让我们专注于这个 为铬开发。”

但是现在,在2014年,while循环又回到了chrome上。它快了2倍,在其他/旧浏览器上它总是更快。

最近我做了一些新的测试。现在在现实环境中,这些短代码毫无价值,jsperf实际上不能正确执行while循环,因为它需要重新创建数组。长度也需要时间。

你无法在jsperf上获得while循环的实际速度。

您需要创建自己的自定义函数,并使用window.performance.now()进行检查。

是的……while循环不可能简单地更快。

真正的问题实际上是dom操作/渲染时间 画图时间,随你怎么叫。

例如,我有一个画布场景,我需要计算坐标和碰撞…这是在10-200微秒(不是毫秒)之间完成的。它实际上需要不同的毫秒来渲染所有内容。和DOM中一样。

BUT

在某些情况下,还有另一种使用for循环的超级性能方式……例如复制/克隆一个数组

for(
 var i = array.length ;
 i > 0 ;
 arrayCopy[ --i ] = array[ i ] // doing stuff
);

注意参数的设置:

与while循环中一样,我只使用一个变量 需要检查索引是否大于0; 正如你所看到的,这种方法与每个人都使用的正常for循环不同,因为i在第3个参数内做东西,并且i也直接在数组内减少。

说到这里,这证实了机器喜欢

我想把它写得短一点,去掉一些无用的东西,用同样的风格写了这篇文章:

for(
 var i = array.length ;
 i-- ;
 arrayCopy[ i ] = array[ i ] // doing stuff
);

即使它更短,但再次使用i似乎会减慢一切。 它比之前的for循环和while循环慢了1/5。

注:;在没有{}的for looo后面非常重要

即使我只是告诉你,jsperf不是测试脚本的最佳方式。我在这里加了两个循环

http://jsperf.com/caching-array-length/40

这里有另一个关于javascript性能的答案

https://stackoverflow.com/a/21353032/2450730

这个答案是为了展示编写javascript的性能方法。所以如果你看不懂,问一下,你会得到答案,或者读一本关于javascript的书http://www.ecma-international.org/ecma-262/5.1/

其他回答

如果顺序不重要,我更喜欢这种风格:

for(var i = array.length; i--; )

它缓存了长度,写起来要短得多。但是它会以相反的顺序遍历数组。

截至2016年6月,在最新的Chrome上做了一些测试(2016年5月,浏览器市场份额为71%,并且还在增加):

The fastest loop is a for loop, both with and without caching length delivering really similar performance. (The for loop with cached length sometimes delivered better results than the one without caching, but the difference is almost negligible, which means the engine might be already optimized to favor the standard and probably most straightforward for loop without caching). The while loop with decrements was approximately 1.5 times slower than the for loop. A loop using a callback function (like the standard forEach), was approximately 10 times slower than the for loop.

我相信这个线程太旧了,它误导程序员认为他们需要缓存长度,或者使用反向遍历,同时递减来获得更好的性能,编写的代码不太容易读懂,更容易出错,而不是简单直接的for循环。因此,我建议:

If your app iterates over a lot of items or your loop code is inside a function that is used often, a straightforward for loop is the answer: for (var i = 0; i < arr.length; i++) { // Do stuff with arr[i] or i } If your app doesn't really iterate through lots of items or you just need to do small iterations here and there, using the standard forEach callback or any similar function from your JS library of choice might be more understandable and less prone to errors, since index variable scope is closed and you don't need to use brackets, accessing the array value directly: arr.forEach(function(value, index) { // Do stuff with value or index }); If you really need to scratch a few milliseconds while iterating over billions of rows and the length of your array doesn't change through the process, you might consider caching the length in your for loop. Although I think this is really not necessary nowadays: for (var i = 0, len = arr.length; i < len; i++) { // Do stuff with arr[i] }

虽然这是一个非常古老的问题,但也是一个非常有趣的问题,

请原谅我稍微改变一下这个问题,但我会在最后回答这个问题。

这个问题让我问自己,在js中是否有更好的循环方法:

所以我做了一些测试,以下是我的发现:

对于1000_000记录:最好是forEach。

对于100条记录:这根本不重要。


回到你刚才的问题:

我创建的例子和问题不完全一样。但我发现了一些有趣的事情:

首先,就像你说的,arr。如果它在比较语句I < arr内,Length每次都会计算。长度……

注意:下面的arrLength变量不超过1000_000条记录的数量。

例如:这不会工作

但是这个会

这需要0.036秒。与数字不变的情况相比,这是非常大的……


总之,

最好使用FOREACH

在你的例子中,i<arr。长度需要更多的时间(通常在1.3左右)

请参阅测试: 查看测试

我已经尝试了一些其他方法来迭代一个巨大的数组,并发现将数组长度减半,然后在一个循环中迭代这两部分更快。这种性能差异可以在处理大型数组时看到。

var firstHalfLen =0;
var secondHalfLen = 0;
var count2=0;
var searchterm = "face";
var halfLen = arrayLength/2;
if(arrayLength%2==halfLen)
{
   firstHalfLen = Math.ceil(halfLen);
   secondHalfLen=Math.floor(halfLen);
}
else
{
   firstHalfLen=halfLen;
   secondHalfLen=halfLen;
}
for(var firstHalfCOunter=0,secondHalfCounter = arrayLength-secondHalfLen;
    firstHalfCOunter < firstHalfLen;
    firstHalfCOunter++)
{
  if(mainArray[firstHalfCOunter].search(new RegExp(searchterm, "i"))> -1)
  {
    count2+=1;
  }
  if(secondHalfCounter < arrayLength)
  {
    if(mainArray[secondHalfCounter].search(new RegExp(searchterm, "i"))> -1)
    {
        count2+=1;
    }
    secondHalfCounter++; 
  }
}

缓存长度for循环与上面的方法之间的一些性能比较(使用timer.js)。

http://jsfiddle.net/tejzpr/bbLgzxgo/

2014年While回来了

要有逻辑性。

看看这个

for( var index = 0 , length = array.length ; index < length ; index++ ) {

 //do stuff

}

需要创建至少2个变量(index,length) 需要检查索引是否小于长度 需要增加索引 for循环有3个参数

现在告诉我为什么这个要比

var length = array.length;

while( --length ) { //or length--

 //do stuff

}

一个变量 没有检查 指数下降(机器更喜欢这样) While只有一个参数

当Chrome 28显示for循环比while快时,我完全困惑了。 这一定是某种

“嗯,每个人都在使用for循环,让我们专注于这个 为铬开发。”

但是现在,在2014年,while循环又回到了chrome上。它快了2倍,在其他/旧浏览器上它总是更快。

最近我做了一些新的测试。现在在现实环境中,这些短代码毫无价值,jsperf实际上不能正确执行while循环,因为它需要重新创建数组。长度也需要时间。

你无法在jsperf上获得while循环的实际速度。

您需要创建自己的自定义函数,并使用window.performance.now()进行检查。

是的……while循环不可能简单地更快。

真正的问题实际上是dom操作/渲染时间 画图时间,随你怎么叫。

例如,我有一个画布场景,我需要计算坐标和碰撞…这是在10-200微秒(不是毫秒)之间完成的。它实际上需要不同的毫秒来渲染所有内容。和DOM中一样。

BUT

在某些情况下,还有另一种使用for循环的超级性能方式……例如复制/克隆一个数组

for(
 var i = array.length ;
 i > 0 ;
 arrayCopy[ --i ] = array[ i ] // doing stuff
);

注意参数的设置:

与while循环中一样,我只使用一个变量 需要检查索引是否大于0; 正如你所看到的,这种方法与每个人都使用的正常for循环不同,因为i在第3个参数内做东西,并且i也直接在数组内减少。

说到这里,这证实了机器喜欢

我想把它写得短一点,去掉一些无用的东西,用同样的风格写了这篇文章:

for(
 var i = array.length ;
 i-- ;
 arrayCopy[ i ] = array[ i ] // doing stuff
);

即使它更短,但再次使用i似乎会减慢一切。 它比之前的for循环和while循环慢了1/5。

注:;在没有{}的for looo后面非常重要

即使我只是告诉你,jsperf不是测试脚本的最佳方式。我在这里加了两个循环

http://jsperf.com/caching-array-length/40

这里有另一个关于javascript性能的答案

https://stackoverflow.com/a/21353032/2450730

这个答案是为了展示编写javascript的性能方法。所以如果你看不懂,问一下,你会得到答案,或者读一本关于javascript的书http://www.ecma-international.org/ecma-262/5.1/