在JavaScript中，我們應該盡可能的用局部變數來取代全域變量，這句話所有人都知道，可是這句話是誰先說的？為什麼要這麼做？有什麼根據麼？不這麼做，對性能到底能帶來多大的損失？本文就來探討這些問題的答案，從根本上了解變數的讀寫表現都和哪些因素有關。
【原文】JavaScript variable performance
【作者】Nicholas C. Zakas
【譯文】在JavaScript中，為什麼要盡量使用局部變數？
【譯者】明達
以下是原文的翻譯：
在如何提升JavaScript效能這個問題上，大家最常聽到的建議應該就是盡量使用局部變數（local variables）來取代全域變數（global variables）。在我從事網路開發工作的九年時間裡，這條建議始終縈繞在我的耳邊，並且從來沒有質疑過，而這條建議的基礎，則來自於JavaScript處理作用域（scoping）和標識符解析（identifier resolution）的方法。
首先我們要明確，函數在JavaScript中具體表現為對象，創建一個函數的過程，其實也就是創建一個對象的過程。每個函數物件都有一個叫做[[Scope]]的內部屬性，這個內部屬性包含建立函數時的作用域資訊。實際上，[[Scope]]屬性對應的是一個物件（Variable Objects）列表，列表中的物件是可以從函數內部存取的。比如說我們建立一個全域函數A，那麼A的[[Scope]]內部屬性中只包含一個全域物件（Global Object），而如果我們在A中建立一個新的函數B，那麼B的[[Scope] ]屬性中就包含兩個對象，函數A的Activation Object對像在前面，全域對象（Global Object）排在後面。
當一個函數被執行的時候，會自動建立一個可以執行的物件（Execution Object），並同時綁定一個作用域鏈（Scope Chain）。作用域鏈會透過下面兩個步驟來建立，用於進行標識符解析。
1. 先將函數物件[[Scope]]內部屬性中的對象，依序複製到作用域鏈中。
2. 其次，在函數執行時，會建立一個新的Activation Object對象，這個物件中包含了this、參數（arguments）、局部變數（包括命名的參數）的定義，這個Activation Object物件會被置於作用域鏈的最前面。
在執行JavaScript程式碼的過程中，當遇到一個標識符，就會根據標識符的名稱，在執行上下文（Execution Context）的作用域鏈中進行搜尋。從作用域鏈的第一個物件（該函數的Activation Object物件）開始，如果沒有找到，就搜尋作用域鏈中的下一個對象，如此往復，直到找到了標識符的定義。如果在搜尋完作用域中的最後一個對象，也就是全域物件（Global Object）以後也沒有找到，則會拋出一個錯誤，提示使用者該變數未定義（undefined）。這是在ECMA-262標準中所描述的函數執行模型和標識符解析（Identifier Resolution）的過程，事實證明，大部分的JavaScript引擎確實也是這樣實現的。要注意的是，ECMA-262並沒有強制要求採用這種結構，只是對這部分功能加以描述而已。
了解標識符解析（Identifier Resolution）的過程以後，我們就能明白為什麼局部變數的解析速度要比其他作用域的變數快，主要是因為搜尋過程被大幅縮短了。但是，具體會快多少呢？為了回答這個問題，我模擬了一系列的測試，來測試不同作用域深度中變數的表現。
第一個測試是寫入變數的一個最簡單值（這裡使用字面量的數值1），結果如下圖顯示，很有趣：
從結果中不難看出，當標識符解析的過程需要進行深度搜尋時，會伴隨效能損失，而且效能損失的程度會隨著標識符深度的增加而遞增。意料之中的是，Internet Explorer表現的是最差的（但公平的說，IE 8還是有一些改善的）。值得注意的是，這裡有一些例外情況，Google Chrome和最新的WebKit午夜版在存取變數的時間保持得很穩定，不會隨著作用域深度的遞增而增長。當然，這應該歸功於它們所使用的下一代JavaScript引擎，V8和SquirrelFish。這些引擎在執行程式碼時進行了最佳化，而且很明顯，這些最佳化使存取變數的速度比以往更快。 Opera表現的也很不錯，比IE、Firefox和目前版本的Safari要快的多，但比基於V8和Squirrelfish的瀏覽器慢。 Firefox 3.1 Beta 2的表現有點出乎意料，對於局部變數執行的效率非常高，但隨著作用域層數的增加，效率便大打折扣。要注意的是，我這裡使用的都是預設設置，也就是說Firefox是沒有開啟Trace功能的。
上面的結果是透過對變數執行寫入操作而得出的，其實我很好奇，讀取變數時的情況會不會有什麼不同，於是接著做了下面的測試。結果發現，讀的速度要比寫的速度快一些，但是效能變化的趨勢是一致的。
和上個測試一樣，Internet Explorer和Firefox還是最慢的，Opera表現了非常搶眼的性能，而同樣的，Chrome和最新版本的Webkit午夜版顯示了和作用域深度無關的性能趨勢，同樣需要注意的是，Firefox 3.1 Beta 2的變數存取時間還是會伴隨著深度出現一個奇怪的跳躍。
在測試的過程中，我發現一個有趣的現象，就是Chrome在存取全域變數的時候會有額外的效能損失。存取全域變數的時間和作用域層數沒有關係，但是會比存取同樣層數的局部變數的時間多出50%。
這兩個測驗可以帶給我們什麼啟示呢？首先是驗證了那個古老的觀點，就是要盡可能的使用局部變數。在所有的瀏覽器下，存取局部變數都比存取跨作用域的變數要快，當然也包含全域變數。下面這幾點應該是透過這個測試得出的經驗吧：
* 仔細檢查函數中所有使用的變量，如果有一個變量不是當前作用域定義的，而且使用了不止一次，那麼我們就應該把這個變量保存在局部變數中，而使用這個局部變數來進行讀寫操作。這樣可以幫助我們將作用域外的變數的搜尋深度減少到1.這對全域變數特別重要，因為全域變數總是被放到作用域鏈的最後位置來搜尋。
* 避免使用with語句。因為它會修改執行上下文（Execution Context）的作用域鏈，在最前面加上一個物件（Variable Object）。這意味著在執行with的過程中，實際上的局部變數都被移到作用域鏈上的第二個位置，這會帶來效能上的損失。
* 如果你確定一段程式碼一定會拋出例外，那麼就要避免使用try-catch，因為catch分支在作用域鏈上的處理方法和with是一樣的。但try分支的程式碼是沒有效能損失的，所以還是建議用try-catch來捕捉那些不可預測的錯誤。
如果你想圍繞這個主題展開更多的討論，我在上個月的Mountain View JavaScript Meetup中曾經發表了一個小演講。可以在SlideShare上下載幻燈片，或觀看派對的完整視頻，我的演講大概從11分鐘左右時開始。
譯者筆記
大家如果在閱讀本文的過程中，有什麼疑惑，建議延伸閱讀以下兩篇文章：
* Richie寫的《JavaScript物件模型-執行模型》
* 《ECMA-262第三版》，主要看看第十章，就是執行上下文（Execution Context）那張，本文提到的名詞在那裡都有詳細的解釋。
在最後的時候，Nicholas提到一個Mountain View JavaScript Meetup，Meetup那個網站其實就是一個各種現實世界活動的組織網站，需要翻牆才能訪問，住在California真幸福，有那麼多的好活動可以參加，呵呵。