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

不過(guò)，說(shuō)實(shí)話，即使它這么瘋狂流行，它的性能還沒(méi)有達(dá)到它的極限。是的，它在改進(jìn)，但是等到它在各個(gè)方面趕上本地應(yīng)用之前，在做一個(gè)HYBIRD混合應(yīng)用時(shí)，你還不得不使用一些伎倆來(lái)優(yōu)化它的性能。

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

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

別扯了舉個(gè)例子吧!

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

眼見(jiàn)為實(shí)，我要添加為第一個(gè)添加jsperf測(cè)試用例，使用的是Firefox38和Chrome39測(cè)試。

＃1不要類型轉(zhuǎn)換

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

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

測(cè)試用例

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

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

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

parseInt 測(cè)試 ~ parseFloat 測(cè)試

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

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

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

＃2不要重新構(gòu)造對(duì)象

重組對(duì)象不便宜，應(yīng)該避免它：

不要使用delete運(yùn)算符

刪除操作比分配一個(gè)null屬性慢很多。分配null在兩個(gè)瀏覽器都快99％，但它不能修改對(duì)象的結(jié)構(gòu)，但刪除可以。

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

delete vs null

不要以后再添加屬性

盡量不要在以后再添加屬性，最好從一開(kāi)始就定義對(duì)象的架構(gòu)。這在Firefox中快100％，在Chrome中快89％。

動(dòng)態(tài)屬性VS預(yù)先定義結(jié)構(gòu)

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

字符串聯(lián)連是一個(gè)非常昂貴的操作，但是應(yīng)該用什么方法呢？當(dāng)然不是Array.prototype.join。

+=運(yùn)算符似乎比+快很多，String.prototype.concat和Array.prototype.join在兩種瀏覽器都更快。Array.prototype.join是最慢的，符合市場(chǎng)預(yù)期。

字符串連接測(cè)試

＃4正確的使用正則表達(dá)式

使用RegExp.prototype.exec是沒(méi)有必要，不是嗎？

然而，RegExp.prototype.test和String.prototype.search之間是有性能差異的，讓我們來(lái)看看哪個(gè)方法更快：

正則表達(dá)式的方法

RegExp.prototype.exec比String.prototype.match快了不少，但他們是不完全一樣的東西，它們的區(qū)別超出了本文的范圍，看這個(gè)問(wèn)答。

RegEx.prototype.test更快，可能是因?yàn)樗环祷卣业狡ヅ涞乃饕?String.prototype.search應(yīng)僅用于找到所需的匹配的索引。

然而，你不應(yīng)該使用正則表達(dá)式來(lái)查找另一個(gè)字符串的位置，你可以使用String.prototype.indexOf方法。

String.prototype.search VS String.prototype.indexOf

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

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

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

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

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

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

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

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

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

用純JavaScript100％完成同樣的功能100%的速度更快，這是JSPerf基準(zhǔn)測(cè)試

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

原文地址： medium.com