有這么一個題目：找出由數(shù)字組成的數(shù)組中最大值的索引。 （PS：不用考慮兼容性）

三個方案中，方案一最傳統(tǒng)最直接明了，相信也是大部分人腦海里最早浮現(xiàn)出來的方案；方案二比方案一更簡潔，使用reduce方法替換了for循環(huán)；方案三最簡潔，沒有循環(huán)，沒有條件判斷，一行代碼解決問題。大部分人都喜歡追求代碼簡潔優(yōu)雅，要是可選的話，相信很多人都會選擇方案三。

但問題來了，這三個方案中哪一個性能最好呢？

• 方案一：性能最差，因為它需要手動去遍歷數(shù)組，并且每個遍歷都需要進行條件判斷，所以這里的性能損耗最大；
• 方案二：性能較好，因為它使用了JavaScript內(nèi)置的reduce函數(shù)幫我們完成了方案一中手動完成的數(shù)組遍歷工作；JavaScript內(nèi)置的方法肯定是比我們自己實現(xiàn)的要快，因此在同樣需要條件判斷的情況下，方案二肯定是由于方案一；
• 方案三：性能最好，因為相對方案二，它連條件判斷都省了，使用了Math.max替代。

但實際情況真的如上面所猜測的嗎？下面我們來做個測試：

測試地址：

indexOfMax-100,000   http://jsperf.com/indexofmax

indexOfMax-120,000   http://jsperf.com/indexofmax-120000

indexOfMax-130,000   http://jsperf.com/indexofmax-130000

測試結(jié)果如下：

從結(jié)果中可以看得出來，性能上：方案一最好，方案三次之，方案二最差；與上面猜測的結(jié)果完全相反。方案一最好猜測應(yīng)該是瀏覽器JavaScript解釋引擎對代碼進行了優(yōu)化后執(zhí)行的結(jié)果，優(yōu)化后的代碼從底層實現(xiàn)上來看應(yīng)該是比reduce、indexOf、Math.max等底層接口的性能更好，因此效率更高。

同時注意到，在Chrome下，當(dāng)數(shù)組長度達到130,000時瀏覽器拋出了最大調(diào)用堆棧的異常，我此前說過，瀏覽器對調(diào)用堆棧的大小是有限制的。不同瀏覽器對函數(shù)最大參數(shù)長度的限制是不一樣的，所以這里需要注意下。

高級瀏覽器的表現(xiàn)似乎比較統(tǒng)一，那么IE的表現(xiàn)又怎么樣呢？

IE下測試結(jié)果如下：

由于IE10、IE11越發(fā)往標(biāo)準(zhǔn)瀏覽器靠攏，他們的表現(xiàn)跟IE9不同，倒與Chrome、Firefox有點類似，也是方案一最快，但是方案三最慢。這可能跟每個瀏覽器自身的實現(xiàn)以及內(nèi)部優(yōu)化有關(guān)系。

So，做性能優(yōu)化時的幾點建議：

• 內(nèi)置的函數(shù)不一定是效率最好的，最簡潔優(yōu)雅的寫法不一定可以帶來性能上的提升；
• JavaScript雖然是解釋型語言，但并不代表所做的操作越少性能越好；
• 要考慮不同平臺以及瀏覽器對接口的性能差異，按需權(quán)衡；
• 盡可能保持簡單的思考方式，不要過度設(shè)計，當(dāng)發(fā)現(xiàn)性能問題時再嘗試去尋找解決方案;
• 性能優(yōu)化需要數(shù)據(jù)支持，不能盲目相信經(jīng)驗或者固有認(rèn)知。

標(biāo)簽： 網(wǎng)站性能優(yōu)化 Javascript 代碼優(yōu)化 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。