Question

我已经阅读了关于循环优化（N.Zakas，Javascript Optimization）的内容。在那里，有人写道，inverse loop使用arrays比直接循环更优化。这似乎完全合乎逻辑：

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

- 检查条件
- 增加变量i

for(i = length;i--;)

- 检查条件+增加变量i（在一个表达式中）
但是，我对Chrome有意想不到的结果。

var len = 100000000,
arr = new Array(len),
i = len - 1,
start = new Date(), 
end;

for(i = 0; i < len; i++){
    arr[i] = 1;
}

end = new Date();

console.log(end - start);

直接循环返回结果接近4500ms，但是反转循环... 9500ms！

为什么？

Answer 1

仅仅因为import csv with open(filename) as f: reader = csv.reader(f) csv_rows = list(reader)中的代码较少并不意味着事情的完成就会减少; for(i = length;i--;)仍然需要增加（或者在这种情况下，递减），并且仍然需要进行检查（在它i之前，它现在是i < length ）。

我可能期望时间上的差异是由于i != 0是一个非常常见的结构，因此非常常见（因此现代编译器/解释器有资源投入明确优化这些）。但我承认这是猜测。

向后迭代可能会显示速度大幅增加的一种情况是当你弹出数组的内容时：

for(i = 0; i < length; i++)可能会从数组中移除第一个元素，并向后移动所有其他元素以填充其位置。

，而：

for(i = 0; i < arr.length; i++) arr.splice(i,1);可能只需要减少引擎盖下阵列的长度（便宜得多！）。

我不确定这是否是您要进行的优化，但是不是＆＃34;向后迭代更快！＆＃34;在一般意义上。

Answer 2

是的，iterating an array backwards can be faster。但那不是你在这里做的。你正在反向构建一个数组，这很奇怪（读：不太可能优化）。

如果你首先开始分配最高的索引，我猜数组是以稀疏数组开始的，这比连续数组效率低得多。一旦引擎实现你正在做的事情，任务本身将会更慢，或转换为正常数组相反，如果从test@ubuntu:~# updatedb # To update the locate database test@ubuntu:~# locate sparse_hash_map /usr/include/google/sparsehash/sparse_hash_map test@ubuntu:~# ln -s /usr/include/google/sparsehash/sparse_hash_map /usr/include/google/sparse_hash_map开始，引擎可以根据需要增长数组，并从一开始就使用高效的内存表示。顺便说一下，我希望arr.fill(1)更快。

循环优化改变方向

2 个答案: