这话我听过好几次了。JavaScript循环在向后计数时真的更快吗?如果有，为什么?我已经看到了一些测试套件示例，它们显示反向循环更快，但我找不到任何解释!
我假设这是因为循环不再需要在每次检查属性时评估它是否已经完成，它只检查最终的数值。
即。
for (var i = count - 1; i >= 0; i--)
{
// count is only evaluated once and then the comparison is always on 0.
}
当前回答
它可以解释为JavaScript(以及所有语言)最终被转换为在CPU上运行的操作码。cpu总是只有一条指令用于与0进行比较，这非常快。
顺便说一句，如果你能保证count总是>= 0，你可以简化为:
for (var i = count; i--;)
{
// whatever
}其他回答
回答这类问题的最好方法就是亲自去尝试。建立一个计算百万次迭代的循环，并以两种方式进行。对两个循环进行计时，并比较结果。
答案可能取决于您使用的浏览器。有些会有不同的结果。
这并不依赖于——或++符号，而是取决于你在循环中应用的条件。
例如:如果变量有一个静态值，那么循环会比每次循环都检查条件(比如数组的长度或其他条件)更快。
但是不用担心这种优化，因为这次它的效果是以纳秒为单位衡量的。
编译器不会缓存。length，因此它没有区别，如果你比较0或。length?我想这对于你正在处理的编译器或解释器是非常特定的。
我想说的是，如果你使用的是一个优化的编译器或解释器，那么你不应该担心这个问题，这是语言开发人员应该担心的问题。
爱死它了，很多分数但没有回答:D
简单地把比较放在零总是最快的比较
因此(a==0)返回True比(a==5)更快
它很小且无关紧要，并且集合中有1亿行，因此它是可测量的。
例如，在循环中，你可能会说where I <= array。长度和I的增量
在下行循环中，你可能会说I >= 0，而不是减去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上的基准测试)。
