讓我們寫快速的JavaScript,JS效能優化小竅門

ourjs發表於2015-02-11

  JavaScript已經是目前最流行的語言了,它能做很多事情 - 網站介面,伺服器端,遊戲 ,作業系統 ,機器人 等等很多很多。

  不過,說實話,即使它這麼瘋狂流行,它的效能還沒有達到它的極限。是的,它在改進,但是等到它在各個方面趕上本地應用之前,在做一個HYBIRD混合應用時,你還不得不使用一些伎倆來優化它的效能。

  Firefox擁有目前最快的JavaScript解析器 SpiderMonkey,

  有各種各樣的讓JavaScript的速度更快的努力,其中一個是asm.js. Asm.js是JavaScript是由Emscripten產生的一個子集,它為C/C++編繹成的JavaScript程式碼做了很多優化,編譯型後的程式碼很難看,這就是為什麼你不能自己寫優化後的程式碼,但它執行非常快。我建議你閱讀一下這篇文章

  別扯了舉個例子吧!

  好了,我們的目標是寫速度更快的JavaScript程式碼,這裡有讓你的程式碼跑得更快一些的小竅門,以及更好的記憶體效率。請注意,我不是嚴格討論DOM和Web應用程式,它是關於JavaScript的,DOM只是一部分。

  眼見為實,我要新增為第一個新增jsperf測試用例,使用的是Firefox38和Chrome39測試。

  #1不要型別轉換

  JavaScript是動態型別,但如果你想提高速度不要使用該功能。儘量保持變數的型別一致。這也適用於陣列,儘管主要是由瀏覽器都進行了優化,但儘量不要混用不同型別的陣列。這就是為何編譯成 JavaScript的C/C++程式碼使用靜態型別的原因之一。

{
  var x = '2';
  var y = 5;
  x = 2;
  x + y;
}

  測試用例

  另外: 字串與數字型別間相互轉換

  比方說,你必須將字串轉換為數字,parseInt與parseFloat是最好的方法嗎?讓我們來看看。

parseFloat("100")
+"100"
// 整型
parseInt("100", 10)
"100"|0
"100" >> 0
"100" << 0
// 僅適用於正數
"100" >>> 0

  parseInt 測試  ~ parseFloat 測試

  Firefox對位操作進行了優化,執行的程式碼比parseInt和+運算速度快約99%。而Chrome顯然對位運算子沒有偏愛,他們比parseInt函式還慢62%。

  parseFloat比+運算子在兩種瀏覽器(Firefox 28%,Chrome 39%)上都要快。

  因此,如果你在寫Node/Chrome或Firefox的應用程式?我認為,一般使用parseInt函式是正確的。

  #2不要重新構造物件

  重組物件不便宜,應該避免它:

  不要使用delete運算子

  刪除操作比分配一個null屬性慢很多。分配null在兩個瀏覽器都快99%,但它不能修改物件的結構,但刪除可以。

  編輯:我認為這裡有點誤導,這並不意味著你不應該使用delete操作符,delete運算子有它自己的使用情況,它可以防止物件的記憶體洩漏。

  delete vs null 

  不要以後再新增屬性

  儘量不要在以後再新增屬性,最好從一開始就定義物件的架構。這在Firefox中快100%,在Chrome中快89%。

  動態屬性VS預先定義結構  

  #3字串聯連

  字串聯連是一個非常昂貴的操作,但是應該用什麼方法呢?當然不是Array.prototype.join。

  +=運算子似乎比+快很多,String.prototype.concat和Array.prototype.join在兩種瀏覽器都更快。Array.prototype.join是最慢的,符合市場預期。

  字串連線測試 

  #4正確的使用正規表示式

  使用RegExp.prototype.exec是沒有必要,不是嗎?

  然而,RegExp.prototype.test和String.prototype.search之間是有效能差異的,讓我們來看看哪個方法更快:

  正規表示式的方法

  RegExp.prototype.exec比String.prototype.match快了不少,但他們是不完全一樣的東西,它們的區別超出了本文的範圍,看這個問答

  RegEx.prototype.test更快,可能是因為它不返回找到匹配的索引。 String.prototype.search應僅用於找到所需的匹配的索引。

  然而,你不應該使用正規表示式來查詢另一個字串的位置,你可以使用String.prototype.indexOf方法。

  String.prototype.search VS String.prototype.indexOf

  另一個有趣的基準是String.prototype.indexOf VS RegExp.prototype.test,我個人預計後者要快,這是在Firefox中發生的事情,但在Chrome中,事實並非如此。 RegExp.prototype.test在Firefox中快32%,而在Chrome中String.prototype.indexOf快33%。在這種情況下,你自己選擇喜歡的方式吧。

  #5限制宣告/傳遞變數的範圍(作用域)

  假如你呼叫一個函式,瀏覽器必須做一些所謂的範圍查詢,它的昂貴程度取決於它要查詢多少範圍。儘量不要依辣全域性/高範圍的變數,儘量使區域性範圍變數,並將它們傳遞給函式。更少的範圍查詢,更少的犧牲速度。

  這個測試告訴我們,從區域性範圍內傳遞和使用變數比從更高的宣告範圍查詢變數快,無論是Chrome和Firefox。

  內部範圍VS高範圍VS全域性

  #6你不需要所有的東西都用jQuery

  大多數開發者使用jQuery做一些簡單的任務,我的意思在一些場合你沒有必要使用jQuery,你覺得用$.val()始終是必要的嗎?就拿這個例子:

$('input').keyup(function() {
    if($(this).val() === 'blah') { ... }
});

  這是學習如何使用JavaScript修改DOM的最重要原因之一,這樣你可以編寫更高效的程式碼。

  用純JavaScript100%完成同樣的功能100%的速度更快,這是JSPerf基準測試

$('input').keyup(function() {
  if(this.value === 'blah') { ... }
});

  原文地址: medium.com

相關文章