本文譯自Nicholas C. Zakas于2009年2月10日在個人網(wǎng)站上發(fā)表的《JavaScript Variable Performance》。原文是唯一的正式版，本文是經(jīng)過原作者（Nicholas C. Zakas）授權(quán)的簡體中文翻譯版（Simplified Chinese Translation）。譯者（明達(dá)）在翻譯的準(zhǔn)確性上做了大量的努力，并承諾譯文的內(nèi)容完全忠于原文，但可能還是包含疏漏和不妥之處，歡迎大家指正。譯注的內(nèi)容是非正式的，僅代表譯者個人觀點。

以下是對原文的翻譯：

在如何提高JavaScript性能這個問題上，大家最常聽到的建議應(yīng)該就是盡量使用局部變量（local variables）來代替全局變量（global variables）。在我從事Web開發(fā)工作的九年時間里，這條建議始終縈繞在我的耳邊，并且從來沒有質(zhì)疑過，而這條建議的基礎(chǔ)，則來自于 JavaScript處理作用域（scoping）和標(biāo)識符解析（identifier resolution）的方法。

首先我們要明確，函數(shù)在JavaScript中具體表現(xiàn)為對象，創(chuàng)建一個函數(shù)的過程，其實也就是創(chuàng)建一個對象的過程。每個函數(shù)對象都有一個叫做 [[Scope]]的內(nèi)部屬性，這個內(nèi)部屬性包含創(chuàng)建函數(shù)時的作用域信息。實際上，[[Scope]]屬性對應(yīng)的是一個對象（Variable Objects）列表，列表中的對象是可以從函數(shù)內(nèi)部訪問的。比如說我們建立一個全局函數(shù)A，那么A的[[Scope]]內(nèi)部屬性中只包含一個全局對象（Global Object），而如果我們在A中創(chuàng)建一個新的函數(shù)B，那么B的[[Scope]]屬性中就包含兩個對象，函數(shù)A的Activation Object對象在前面，全局對象（Global Object）排在后面。

當(dāng)一個函數(shù)被執(zhí)行的時候，會自動創(chuàng)建一個可以執(zhí)行的對象（Execution Object），并同時綁定一個作用域鏈（Scope Chain）。作用域鏈會通過下面兩個步驟來建立，用于進(jìn)行標(biāo)識符解析。

1. 首先將函數(shù)對象[[Scope]]內(nèi)部屬性中的對象，按順序復(fù)制到作用域鏈中。
2. 其次，在函數(shù)執(zhí)行時，會創(chuàng)建一個新的Activation Object對象，這個對象中包含了this、參數(shù)（arguments）、局部變量（包括命名的參數(shù)）的定義，這個Activation Object對象會被置于作用域鏈的最前面。

在執(zhí)行JavaScript代碼的過程中，當(dāng)遇到一個標(biāo)識符，就會根據(jù)標(biāo)識符的名稱，在執(zhí)行上下文（Execution Context）的作用域鏈中進(jìn)行搜索。從作用域鏈的第一個對象（該函數(shù)的Activation Object對象）開始，如果沒有找到，就搜索作用域鏈中的下一個對象，如此往復(fù)，直到找到了標(biāo)識符的定義。如果在搜索完作用域中的最后一個對象，也就是全局對象（Global Object）以后也沒有找到，則會拋出一個錯誤，提示用戶該變量未定義（undefined）。這是在ECMA-262標(biāo)準(zhǔn)中描述的函數(shù)執(zhí)行模型和標(biāo)識符解析（Identifier Resolution）的過程，事實證明，大部分的JavaScript引擎確實也是這樣實現(xiàn)的。需要注意的是，ECMA-262并沒有強制要求采用這種結(jié)構(gòu)，只是對這部分功能加以描述而已。

了解標(biāo)識符解析（Identifier Resolution）的過程以后，我們就能明白為什么局部變量的解析速度要比其他作用域的變量快，主要是由于搜索過程被大幅縮短了。但是，具體會快多少呢？為了回答這個問題，我模擬了一系列的測試，來測試不同作用域深度中變量的性能。

第一個測試是向一個變量中寫入一個最簡單的值（這里使用字面量的數(shù)值1），結(jié)果如下圖顯示，很有趣：

從結(jié)果中不難看出，當(dāng)標(biāo)識符解析的過程需要進(jìn)行深度搜索時，會伴隨性能損失，而且性能損失的程度會隨著標(biāo)識符深度的增加而遞增。意料之中的是，InterNET Explorer表現(xiàn)的是最差的（但公平的說，IE 8還是有一些改善的）。值得注意的是，這里有一些例外情況，Google Chrome和最新的WebKit午夜版在訪問變量的時間保持得很穩(wěn)定，不會隨著作用域深度的遞增而增長。當(dāng)然，這應(yīng)該歸功于它們所使用的下一代 JavaScript引擎，V8和SquirrelFish。這些引擎在執(zhí)行代碼時進(jìn)行了優(yōu)化，而且很明顯，這些優(yōu)化使訪問變量的速度比以往更快。 Opera表現(xiàn)的也很不錯，比IE、Firefox和當(dāng)前版本的Safari要快的多，但比基于V8和Squirrelfish的瀏覽器要慢。 Firefox 3.1 Beta 2的表現(xiàn)有點出人意料，對于局部變量執(zhí)行的效率非常高，但隨著作用域?qū)訑?shù)的增加，效率便大打折扣。需要注意的是，我這里使用的都是默認(rèn)設(shè)置，也就是說 Firefox是沒有開啟Trace功能的。

上面的結(jié)果是通過對變量執(zhí)行寫操作而得出的，其實我很好奇，讀取變量時的情況會不會有什么不同，于是接著做了下面的測試。結(jié)果發(fā)現(xiàn)，讀的速度要比寫的速度快一些，但是性能變化的趨勢是一致的。

和上個測試一樣，InterNET Explorer和Firefox還是最慢的，Opera表現(xiàn)了非常搶眼的性能，而同樣的，Chrome和最新版本的Webkit午夜版顯示了和作用域深度無關(guān)的性能趨勢，同樣需要注意的是，F(xiàn)irefox 3.1 Beta 2的變量訪問時間還是會伴隨著深度出現(xiàn)一個奇怪的跳躍。

在測試的過程中，我發(fā)現(xiàn)一個有趣的現(xiàn)象，就是Chrome在訪問全局變量的時候會有額外的性能損失。訪問全局變量的時間和作用域?qū)訑?shù)沒有關(guān)系，但是會比訪問同樣層數(shù)的局部變量的時間多出50%。

這兩個測試可以給我們帶來什么啟示呢？首先是驗證了那個古老的觀點，就是要盡可能的使用局部變量。在所有的瀏覽器下，訪問局部變量都比訪問跨作用域的變量要快，當(dāng)然也包括全局變量。下面這幾點應(yīng)該是通過這個測試得出的經(jīng)驗吧：

* 仔細(xì)檢查函數(shù)中所有使用的變量，如果有一個變量不是當(dāng)前作用域定義的，而且使用了不止一次，那么我們就應(yīng)該把這個變量保存在局部變量中，而使用這個局部變量來進(jìn)行讀寫操作。這樣可以幫助我們將作用域外的變量的搜索深度減少到1.這對全局變量尤為重要，因為全局變量總是被放到作用域鏈的最后位置來搜索。
* 避免使用with語句。因為它會修改執(zhí)行上下文（Execution Context）的作用域鏈，在最前面添加一個對象（Variable Object）。這就意味著在執(zhí)行with的過程中，實際上的局部變量都被移到作用域鏈上的第二個位置，這會帶來性能上的損失。
* 如果你確定一段代碼肯定會拋出異常，那么就要避免使用try-catch，因為catch分支在作用域鏈上的處理方法和with是一樣的。但try分支的代碼是沒有性能損失的，所以還是建議用try-catch來捕獲那些不可預(yù)知的錯誤。

如果你想圍繞這個話題展開更多的討論，我在上個月的Mountain View JavaScript Meetup中曾經(jīng)發(fā)表了一個小演講。可以在SlideShare上下載幻燈片，或者觀看聚會的完整視頻，我的演講大概從11分鐘左右時開始。

譯者筆記

大家如果在閱讀本文的過程中，有什么疑惑，建議延伸閱讀以下兩篇文章：
* Richie寫的《JavaScript對象模型-執(zhí)行模型》
* 《ECMA-262第三版》，主要看看第十章，就是執(zhí)行上下文（Execution Context）那張，本文提到的名詞在那里都有詳細(xì)的解釋。

在最后的時候，Nicholas提到一個Mountain View JavaScript Meetup，Meetup那個網(wǎng)站其實就是一個各種現(xiàn)實世界活動的組織網(wǎng)站，需要翻墻才能訪問，住在California真幸福，有那么多的好活動可以參加，呵呵。

JavaScript技術(shù)：在JavaScript中，為什么要盡可能使用局部變量？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。