这话我听过好几次了。JavaScript循环在向后计数时真的更快吗?如果有,为什么?我已经看到了一些测试套件示例,它们显示反向循环更快,但我找不到任何解释!

我假设这是因为循环不再需要在每次检查属性时评估它是否已经完成,它只检查最终的数值。

即。

for (var i = count - 1; i >= 0; i--)
{
  // count is only evaluated once and then the comparison is always on 0.
}

当前回答

这只是一个猜测,但这可能是因为处理器更容易将某个值与0 (i >= 0)进行比较,而不是与另一个值(i < Things.length)进行比较。

其他回答

这个人比较了javascript和很多浏览器中的循环。他还提供了一个测试套件,您可以自己运行这些测试。

在所有情况下(除非我在阅读中遗漏了一个),最快的循环是:

var i = arr.length; //or 10
while(i--)
{
  //...
}

有时,对代码的编写方式做一些非常小的更改,可能会对代码的实际运行速度产生很大的影响。一个微小的代码更改可能会对执行时间产生很大影响的地方是我们有一个处理数组的for循环。当数组是网页上的元素(如单选按钮)时,这种改变的影响最大,但即使数组是Javascript代码的内部,也值得应用这种改变。

编写for循环来处理数组的常规方法如下:

for (var i = 0; i < myArray.length; i++) {...

The problem with this is that evaluating the length of the array using myArray.length takes time and the way that we have coded the loop means that this evaluation has to be performed every time around the loop. If the array contains 1000 elements then the length of the array will be evaluated 1001 times. If we were looking at radio buttons and had myForm.myButtons.length then it will take even longer to evaluate since the appropriate group of buttons within the specified form must first be located before the length can be evaluated each time around the loop.

显然,我们不希望数组的长度在处理时发生变化,因此所有这些重新计算长度的操作只是不必要地增加了处理时间。(当然,如果你在循环中有添加或删除数组条目的代码,那么数组大小可以在迭代之间改变,所以我们不能改变测试它的代码)

对于一个大小固定的循环,我们能做的就是在循环开始时计算长度,并将其保存在一个变量中。然后,我们可以测试变量以决定何时终止循环。这比每次计算数组长度要快得多,特别是当数组包含多个条目或是网页的一部分时。

这样做的代码是:

for (var i = 0, var j = myArray.length; i < j; i++) {...

因此,现在我们只计算数组的大小一次,并在每次循环中测试循环计数器是否包含该值的变量。访问这个额外的变量比计算数组的大小要快得多,因此我们的代码将比以前运行得快得多。我们的脚本中只有一个额外的变量。

通常情况下,处理数组的顺序并不重要,只要数组中的所有条目都得到了处理。在这种情况下,我们可以通过去掉刚刚添加的额外变量并以相反的顺序处理数组来使代码稍微快一些。

以最有效的方式处理数组的最终代码是:

for (var i = myArray.length-1; i > -1; i--) {...

这段代码仍然只在开始时计算一次数组的大小,但不是将循环计数器与变量进行比较,而是将其与常量进行比较。由于访问常量比访问变量更有效,并且由于我们的赋值语句比以前少了一个,所以第三个版本的代码现在比第二个版本的效率略高,比第一个版本的效率要高得多。

我在《Sublime Text 2》中看到了同样的建议。

如前所述,主要的改进不是在for循环的每次迭代中计算数组的长度。这是一种众所周知的优化技术,当数组是HTML文档的一部分时,在JavaScript中特别有效(为所有li元素执行for)。

例如,

For (var I = 0;i < document.getElementsByTagName('li').length;我+ +)

慢得多

for (was i = 0, len = document.getElementsByTagName('li').length; in < fief; i++)

在我看来,你的问题中表单的主要改进是它没有声明一个额外的变量(在我的例子中是len)

但如果你问我,我认为重点不在于i++ vs i——优化,而在于不必在每次迭代时计算数组的长度(您可以看到jsperf上的基准测试)。

既然你对这个主题感兴趣,可以看看Greg Reimer关于JavaScript循环基准的博客文章,用JavaScript编写循环的最快方法是什么?:

我为JavaScript中不同的循环编码方式构建了一个循环基准测试套件。现在已经有一些这样的工具了,但是我还没有找到任何一个能够区分原生数组和HTML集合的工具。

您还可以通过打开https://blogs.oracle.com/greimer/resource/loop-test.html对循环进行性能测试(如果JavaScript在浏览器中被NoScript阻塞,则无法工作)。

编辑:

Milan Adamovsky最近创建的基准测试可以在运行时针对不同的浏览器执行。

在Mac OS X 10.6上的Firefox 17.0测试中,我得到了以下循环:

简短的回答

对于普通代码,特别是在像JavaScript这样的高级语言中,i++和i——在性能上没有区别。

性能标准是在for循环和compare语句中的使用。

这适用于所有高级语言,并且基本上独立于JavaScript的使用。解释是最后一行的汇编代码。

详细解释

在循环中可能会出现性能差异。背景是,在汇编代码级别上,您可以看到compare with 0只是一个语句,不需要额外的寄存器。

这种比较是在循环的每一次传递中进行的,可能会导致可测量的性能改进。

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

将被求值为如下的伪代码:

 i=array.length
 :LOOP_START
 decrement i
 if [ i = 0 ] goto :LOOP_END
 ... BODY_CODE
 :LOOP_END

注意,0是一个字面值,或者换句话说,是一个常量值。

for(var i = 0 ; i < array.length; i++ )

将被计算为如下的伪代码(假设是正常的解释器优化):

 end=array.length
 i=0
 :LOOP_START
 if [ i < end ] goto :LOOP_END
 increment i
 ... BODY_CODE
 :LOOP_END

注意,end是一个需要CPU寄存器的变量。这可能会在代码中调用额外的寄存器交换,并且需要在if语句中使用更昂贵的compare语句。

只是我的5美分

对于高级语言来说,可读性(有助于可维护性)作为一种较小的性能改进更为重要。

通常,从数组开始到结束的经典迭代更好。

从数组末端到开始的快速迭代会导致可能不需要的反向序列。

附言

正如在评论中问到的:-i和i-的区别在于i在递减之前或之后的求值。

最好的解释是尝试一下;-)下面是一个Bash示例。

 % i=10; echo "$((--i)) --> $i"
 9 --> 9
 % i=10; echo "$((i--)) --> $i"
 10 --> 9