JavaScript已經(jīng)是目前最流行的語言了，它能做很多事情 - 網(wǎng)站界面，服務器端，游戲 ，操作系統(tǒng) ，機器人 等等很多很多。

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

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

有各種各樣的讓JavaScript的速度更快的努力，其中一個是asm.js. Asm.js是JavaScript是由Emscripten產(chǎn)生的一個子集，它為C/C++編繹成的JavaScript代碼做了很多優(yōu)化，編譯型后的代碼很難看，這就是為什么你不能自己寫優(yōu)化后的代碼，但它運行非?？?。我建議你閱讀一下這篇文章

別扯了舉個例子吧!

好了，我們的目標是寫速度更快的JavaScript代碼，這里有讓你的代碼跑得更快一些的小竅門，以及更好的內(nèi)存效率。請注意，我不是嚴格討論DOM和Web應用程序，它是關于JavaScript的，DOM只是一部分。

眼見為實，我要添加為第一個添加jsperf測試用例，使用的是Firefox38和Chrome39測試。

＃1不要類型轉換

JavaScript是動態(tài)類型，但如果你想提高速度不要使用該功能。盡量保持變量的類型一致。這也適用于數(shù)組，盡管主要是由瀏覽器都進行了優(yōu)化,但盡量不要混用不同類型的數(shù)組。這就是為何編譯成 JavaScript的C/C++代碼使用靜態(tài)類型的原因之一。

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

測試用例

另外: 字符串與數(shù)字類型間相互轉換

比方說，你必須將字符串轉換為數(shù)字，parseInt與parseFloat是最好的方法嗎？讓我們來看看。

parseFloat("100")+"100"http:// 整型parseInt("100", 10)"100"|0"100" >> 0"100" << 0// 僅適用于正數(shù)"100" >>> 0

parseInt 測試 ~ parseFloat 測試

Firefox對位操作進行了優(yōu)化，運行的代碼比parseInt和+運算速度快約99％。而Chrome顯然對位運算符沒有偏愛，他們比parseInt函數(shù)還慢62％。

parseFloat比+運算符在兩種瀏覽器（Firefox 28％，Chrome 39％）上都要快。

因此，如果你在寫Node/Chrome或Firefox的應用程序？我認為，一般使用parseInt函數(shù)是正確的。

＃2不要重新構造對象

重組對象不便宜，應該避免它：

不要使用delete運算符

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

編輯：我認為這里有點誤導，這并不意味著你不應該使用delete操作符，delete運算符有它自己的使用情況，它可以防止對象的內(nèi)存泄漏。

delete vs null

不要以后再添加屬性

盡量不要在以后再添加屬性，最好從一開始就定義對象的架構。這在Firefox中快100％，在Chrome中快89％。

動態(tài)屬性VS預先定義結構

＃3字符串聯(lián)連

字符串聯(lián)連是一個非常昂貴的操作，但是應該用什么方法呢？當然不是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快了不少，但他們是不完全一樣的東西，它們的區(qū)別超出了本文的范圍，看這個問答。

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

然而，你不應該使用正則表達式來查找另一個字符串的位置，你可以使用String.prototype.indexOf方法。

String.prototype.search VS String.prototype.indexOf

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

＃5限制聲明/傳遞變量的范圍（作用域）

假如你調(diào)用一個函數(shù)，瀏覽器必須做一些所謂的范圍查找，它的昂貴程度取決于它要查找多少范圍。盡量不要依辣全局/高范圍的變量，盡量使局部范圍變量，并將它們傳遞給函數(shù)。更少的范圍查找，更少的犧牲速度。

這個測試告訴我們，從局部范圍內(nèi)傳遞和使用變量比從更高的聲明范圍查找變量快，無論是Chrome和Firefox。

內(nèi)部范圍VS高范圍VS全局

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

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

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

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

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

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

原文地址： medium.com