这话我听过好几次了。JavaScript循环在向后计数时真的更快吗?如果有,为什么?我已经看到了一些测试套件示例,它们显示反向循环更快,但我找不到任何解释!
我假设这是因为循环不再需要在每次检查属性时评估它是否已经完成,它只检查最终的数值。
即。
for (var i = count - 1; i >= 0; i--)
{
// count is only evaluated once and then the comparison is always on 0.
}
这话我听过好几次了。JavaScript循环在向后计数时真的更快吗?如果有,为什么?我已经看到了一些测试套件示例,它们显示反向循环更快,但我找不到任何解释!
我假设这是因为循环不再需要在每次检查属性时评估它是否已经完成,它只检查最终的数值。
即。
for (var i = count - 1; i >= 0; i--)
{
// count is only evaluated once and then the comparison is always on 0.
}
当前回答
编译器不会缓存。length,因此它没有区别,如果你比较0或。length?我想这对于你正在处理的编译器或解释器是非常特定的。
我想说的是,如果你使用的是一个优化的编译器或解释器,那么你不应该担心这个问题,这是语言开发人员应该担心的问题。
其他回答
好吧,我不了解JavaScript,它应该只是一个重新计算数组长度的问题,也许与关联数组有关(如果你只是递减,不太可能需要分配新条目——如果数组是密集的,也就是说。有人可能会为此进行优化)。
在低级汇编中,有一个循环指令,称为DJNZ(如果非零则递减和跳跃)。因此,递减和跳转都在一条指令中,使得它可能比INC和JL / JB略快(递增,如果小于则跳转/如果低于则跳转)。同样,与零比较比与其他数字比较简单。但所有这些都是边缘的,也取决于目标架构(可能会产生不同,例如智能手机上的Arm)。
我没想到这种低级别的差异会对解释语言产生这么大的影响,我只是在回答中没有看到DJNZ,所以我想分享一个有趣的想法。
曾经有人说——i(在c++中)更快,因为只有一个结果,即递减的值。I——需要将减后的值存储回I,并保留原始值作为结果(j = I——;)。在大多数编译器中,这会占用两个而不是一个寄存器,这可能会导致另一个变量必须写入内存,而不是作为寄存器变量保留。
我同意其他人的看法,他们说现在没有什么不同。
你现在做的方式不是更快(除了它是一个无限循环,我猜你的意思是做I——。
如果你想让它更快,请:
for (i = 10; i--;) {
//super fast loop
}
当然,在这么小的循环中你不会注意到它。它更快的原因是因为你在检查i是否为“真”时递减i(当它达到0时,它的计算结果为“假”)
我在《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上的基准测试)。
递减模式的最快方式:
var iteration = 10000000;
while(iteration > 0){
iteration--;
}
速度比:
var iteration = 10000000;
while(iteration--);
Javascript微优化测试