快捷導(dǎo)航

js 數(shù)組的for循環(huán)到底應(yīng)該怎么寫？

更新時(shí)間：2010年05月31日 23:26:05 作者：

說(shuō)實(shí)話，我是個(gè)比較喜歡懷疑權(quán)威的人，但是在有些權(quán)威的問題一直在我面前閃，閃啊閃，我就開始不懷疑他們了，因?yàn)橛?0000個(gè)人說(shuō)這個(gè)東西是對(duì)的，我就會(huì)覺得它的確是對(duì)的吧。

然后來(lái)看看今天我開始懷疑哪個(gè)權(quán)威哦家伙了。。。

自從開始學(xué)編程，自從接觸到數(shù)組這個(gè)東西，我就一直在不同的地點(diǎn)和不同的時(shí)間不斷看到有人提醒：在用for遍歷數(shù)組的時(shí)候一定要用 for(var i=0,n=arr2.length;i<n;i++)的方式哦，而不要用for(var i=0;i>arr.length;i++)的方式哦，因?yàn)橛媚X子想想也知道，第二種方法的第二部分會(huì)一直去計(jì)算數(shù)組的length，所以自然效率比較低。

哦？我們這里不說(shuō)其他程序語(yǔ)言，而只討論js，因?yàn)椴煌恼Z(yǔ)言，實(shí)現(xiàn)可能不同，其他語(yǔ)言是什么情況還要靠大家去探索嘍。其實(shí)上面說(shuō)到的所謂的“動(dòng)腦子想想就知道”也許只是因?yàn)榇蠹抑皇怯媚X子想了想，而不是仔細(xì)想了想或者親自去試了試。所以現(xiàn)在我們仔細(xì)想想，第一種寫法真的會(huì)比第二種寫法快么？arr.length會(huì)耗費(fèi)很多cpu么？不會(huì)啊，為什么要耗費(fèi)cpu呢？arr.length并不是調(diào)用了一個(gè)方法，而只是讀取了一下數(shù)組的length屬性啊，你認(rèn)為讀取原生屬性和讀取定義的變量，哪個(gè)會(huì)快呢？我認(rèn)為讀取length會(huì)更快，所以我寫了個(gè)測(cè)試來(lái)測(cè)試自己的想法：我用了一個(gè)我自己的小測(cè)試框架，

復(fù)制代碼代碼如下:

 
var arr=[],arr2=[],i=0 
while(i<100000){ 
arr.push(i) 
arr2.push(i) 
i++ 
} 
M.TA.begin("0000"); 
for(var i=0;i<arr.length;i++){ 
arr[i]=arr[i]*arr[i]*arr[i] 
} 
M.TA.end("0000","for(var i=0;i<arr.length;i++)") 
M.TA.begin("0001"); 
for(var i=0,n=arr2.length;i<n;i++){ 
arr2[i]=arr2[i]*arr2[i]*arr2[i] 
} 
M.TA.end("0001"," for(var i=0,n=arr2.length;i<n;i++)") 
M.TA.showResult() 

當(dāng)然，這段代碼是很變態(tài)的，占用了300多兆的內(nèi)存。結(jié)果如下：
chrome

firefox

（在做過(guò)N種性能測(cè)試后發(fā)現(xiàn)firefox在基礎(chǔ)運(yùn)算上的效率比chrome高很多，只是涉及到渲染的就慢很多了）
ie8

（減少了N個(gè)數(shù)量級(jí)之后的記過(guò)，上述腳本在ie里無(wú)法運(yùn)行）
總結(jié)：？
其實(shí)做這個(gè)測(cè)試不是為了強(qiáng)調(diào)for(var i=0;i<arr.length;i++)的寫法快多少，因?yàn)闇y(cè)試也是有些許誤差的，只是為了說(shuō)明這種寫法并不會(huì)慢到哪里去，而且這種寫法有一定的靈活性，書寫也簡(jiǎn)單，代碼量又少，那我們?yōu)槭裁床挥盟兀?如果是第一種寫法，在循環(huán)的時(shí)候數(shù)組長(zhǎng)度發(fā)生變化呢？這種情況就處理不了了吧

其實(shí)我還是尊敬權(quán)威的，所以寫到這里的時(shí)候我心里仍然提心吊膽，難道是我哪里搞錯(cuò)了么？如果是，大家就當(dāng)一笑而過(guò)吧，如果不是，那我總算寫了篇人模狗樣的博文了。。。
轉(zhuǎn)載注明：
http://www.html-js.com

您可能感興趣的文章: