編寫高效能的 Lua 程式碼

前言

Lua是一門以其效能著稱的指令碼語言，被廣泛應用在很多方面，尤其是遊戲。像《魔獸世界》的外掛，手機遊戲《大掌門》《神曲》《迷失之地》等都是用Lua來寫的邏輯。

所以大部分時候我們不需要去考慮效能問題。Knuth有句名言：“過早優化是萬惡之源”。其意思就是過早優化是不必要的，會浪費大量時間，而且容易導致程式碼混亂。

所以一個好的程式設計師在考慮優化效能前必須問自己兩個問題：“我的程式真的需要優化嗎？”。如果答案為是，那麼再問自己：“優化哪個部分？”。

我們不能靠臆想和憑空猜測來決定優化哪個部分，程式碼的執行效率必須是可測量的。我們需要藉助於分析器來測定效能的瓶頸，然後著手優化。優化後，我們仍然要藉助於分析器來測量所做的優化是否真的有效。

我認為最好的方式是在首次編寫的時候按照最佳實踐去寫出高效能的程式碼，而不是編寫了一堆垃圾程式碼後，再考慮優化。相信工作後大家都會對事後的優化的繁瑣都深有體會。

一旦你決定編寫高效能的Lua程式碼，下文將會指出在Lua中哪些程式碼是可以優化的，哪些程式碼會是執行緩慢的，然後怎麼去優化它們。

使用local

在程式碼執行前，Lua會把原始碼預編譯成一種中間碼，類似於Java的虛擬機器。這種格式然後會通過C的直譯器進行解釋，整個過程其實就是通過一個while迴圈，裡面有很多的switch...case語句，一個case對應一條指令來解析。

自Lua 5.0之後，Lua採用了一種類似於暫存器的虛擬機器模式。Lua用棧來儲存其暫存器。每一個活動的函式，Lua都會其分配一個棧，這個棧用來儲存函式裡的活動記錄。每一個函式的棧都可以儲存至多250個暫存器，因為棧的長度是用8個位元表示的。

有了這麼多的暫存器，Lua的預編譯器能把所有的local變數儲存在其中。這就使得Lua在獲取local變數時其效率十分的高。

舉個栗子： 假設a和b為local變數，a = a + b的預編譯會產生一條指令：

但是若a和b都沒有宣告為local變數，則預編譯會產生如下指令：

所以你懂的：在寫Lua程式碼時，你應該儘量使用local變數。

以下是幾個對比測試，你可以複製程式碼到你的編輯器中，進行測試。

把math.sin賦給local變數sin：

直接使用math.sin，耗時1.11秒；使用local變數sin來儲存math.sin，耗時0.76秒。可以獲得30%的效率提升！

關於表(table)

表在Lua中使用十分頻繁，因為表幾乎代替了Lua的所有容器。所以快速瞭解一下Lua底層是如何實現表，對我們編寫Lua程式碼是有好處的。

Lua的表分為兩個部分：陣列(array)部分和雜湊(hash)部分。陣列部分包含所有從1到n的整數鍵，其他的所有鍵都儲存在雜湊部分中。

雜湊部分其實就是一個雜湊表，雜湊表本質是一個陣列，它利用雜湊演算法將鍵轉化為陣列下標，若下標有衝突(即同一個下標對應了兩個不同的鍵)，則它會將衝突的下標上建立一個連結串列，將不同的鍵串在這個連結串列上，這種解決衝突的方法叫做：鏈地址法。

當我們把一個新鍵值賦給表時，若陣列和雜湊表已經滿了，則會觸發一個再雜湊(rehash)。再雜湊的代價是高昂的。首先會在記憶體中分配一個新的長度的陣列，然後將所有記錄再全部雜湊一遍，將原來的記錄轉移到新陣列中。新雜湊表的長度是最接近於所有元素數目的2的乘方。

當建立一個空表時，陣列和雜湊部分的長度都將初始化為0，即不會為它們初始化任何陣列。讓我們來看下執行下面這段程式碼時在Lua中發生了什麼：

最開始，Lua建立了一個空表a，在第一次迭代中，a[1] = true觸發了一次rehash，Lua將陣列部分的長度設定為2^0，即1，雜湊部分仍為空。在第二次迭代中，a[2] = true再次觸發了rehash，將陣列部分長度設為2^1，即2。最後一次迭代，又觸發了一次rehash，將陣列部分長度設為2^2，即4。

下面這段程式碼：

與上一段程式碼類似，只是其觸發了三次表中雜湊部分的rehash而已。

只有三個元素的表，會執行三次rehash；然而有一百萬個元素的表僅僅只會執行20次rehash而已，因為2^20 = 1048576 > 1000000。但是，如果你建立了非常多的長度很小的表（比如座標點：point = {x=0,y=0}），這可能會造成巨大的影響。

如果你有很多非常多的很小的表需要建立時，你可以將其預先填充以避免rehash。比如：{true,true,true}，Lua知道這個表有三個元素，所以Lua直接建立了三個元素長度的陣列。類似的，{x=1, y=2, z=3}，Lua會在其雜湊部分中建立長度為4的陣列。

以下程式碼執行時間為1.53秒：

如果我們在建立表的時候就填充好它的大小，則只需要0.75秒，一倍的效率提升！

所以，當需要建立非常多的小size的表時，應預先填充好表的大小。

關於字串

與其他主流指令碼語言不同的是，Lua在實現字串型別有兩方面不同。

第一，所有的字串在Lua中都只儲存一份拷貝。當新字串出現時，Lua檢查是否有其相同的拷貝，若沒有則建立它，否則，指向這個拷貝。這可以使得字串比較和表索引變得相當的快，因為比較字串只需要檢查引用是否一致即可；但是這也降低了建立字串時的效率，因為Lua需要去查詢比較一遍。

第二，所有的字串變數，只儲存字串引用，而不儲存它的buffer。這使得字串的賦值變得十分高效。例如在Perl中，$x = $y，會將$y的buffer整個的複製到$x的buffer中，當字串很長時，這個操作的代價將十分昂貴。而在Lua，同樣的賦值，只複製引用，十分的高效。

但是隻儲存引用會降低在字串連線時的速度。在Perl中，$s = $s . 'x'和$s .= 'x'的效率差距驚人。前者，將會獲取整個$s的拷貝，並將’x’新增到它的末尾；而後者，將直接將’x’插入到$x的buffer末尾。

由於後者不需要進行拷貝，所以其效率和$s的長度無關，因為十分高效。

在Lua中，並不支援第二種更快的操作。以下程式碼將花費6.65秒：

我們可以用table來模擬buffer，下面的程式碼只需花費0.72秒，9倍多的效率提升：

所以：在大字串連線中，我們應避免..。應用table來模擬buffer，然後concat得到最終字串。

3R原則

3R原則（the rules of 3R）是：減量化（reducing），再利用（reusing）和再迴圈（recycling）三種原則的簡稱。

3R原則本是迴圈經濟和環保的原則，但是其同樣適用於Lua。

Reducing

有許多辦法能夠避免建立新物件和節約記憶體。例如：如果你的程式中使用了太多的表，你可以考慮換一種資料結構來表示。

舉個栗子。 假設你的程式中有多邊形這個型別，你用一個表來儲存多邊形的頂點：

以上的資料結構十分自然，便於理解。但是每一個頂點都需要一個雜湊部分來儲存。如果放置在陣列部分中，則會減少記憶體的佔用:

一百萬個頂點時，記憶體將會由153.3MB減少到107.6MB，但是代價是程式碼的可讀性降低了。

最變態的方法是：

一百萬個頂點，記憶體將只佔用32MB，相當於原來的1/5。你需要在效能和程式碼可讀性之間做出取捨。

在迴圈中，我們更需要注意例項的建立。

我們應該把在迴圈中不變的東西放到迴圈外來建立：

Reusing

如果無法避免建立新物件，我們需要考慮重用舊物件。

考慮下面這段程式碼：

在每次迴圈迭代中，都會建立一個新表{year = i, month = 6, day = 14}，但是隻有year是變數。

下面這段程式碼重用了表：

另一種方式的重用，則是在於快取之前計算的內容，以避免後續的重複計算。後續遇到相同的情況時，則可以直接查表取出。這種方式實際就是動態規劃效率高的原因所在，其本質是用空間換時間。

Recycling

Lua自帶垃圾回收器，所以我們一般不需要考慮垃圾回收的問題。

瞭解Lua的垃圾回收能使得我們程式設計的自由度更大。

Lua的垃圾回收器是一個增量執行的機制。即回收分成許多小步驟（增量的）來進行。

頻繁的垃圾回收可能會降低程式的執行效率。

我們可以通過Lua的collectgarbage函式來控制垃圾回收器。

collectgarbage函式提供了多項功能：停止垃圾回收，重啟垃圾回收，強制執行一次回收迴圈，強制執行一步垃圾回收，獲取Lua佔用的記憶體，以及兩個影響垃圾回收頻率和步幅的引數。

對於批處理的Lua程式來說，停止垃圾回收collectgarbage("stop")會提高效率，因為批處理程式在結束時，記憶體將全部被釋放。

對於垃圾回收器的步幅來說，實際上很難一概而論。更快幅度的垃圾回收會消耗更多CPU，但會釋放更多記憶體，從而也降低了CPU的分頁時間。只有小心的試驗，我們才知道哪種方式更適合。

結語

我們應該在寫程式碼時，按照高標準去寫，儘量避免在事後進行優化。

如果真的有效能問題，我們需要用工具量化效率，找到瓶頸，然後針對其優化。當然優化過後需要再次測量，檢視是否優化成功。

在優化中，我們會面臨很多選擇：程式碼可讀性和執行效率，CPU換記憶體，記憶體換CPU等等。需要根據實際情況進行不斷試驗，來找到最終的平衡點。

最後，有兩個終極武器：

第一、使用LuaJIT，LuaJIT可以使你在不修改程式碼的情況下獲得平均約5倍的加速。檢視LuaJIT在x86/x64下的效能提升比。

第二、將瓶頸部分用C/C++來寫。因為Lua和C的天生近親關係，使得Lua和C可以混合程式設計。但是C和Lua之間的通訊會抵消掉一部分C帶來的優勢。

注意：這兩者並不是相容的，你用C改寫的Lua程式碼越多，LuaJIT所帶來的優化幅度就越小。

宣告

這篇文章是基於Lua語言的創造者Roberto Ierusalimschy在Lua Programming Gems 中的Lua Performance Tips翻譯改寫而來。本文沒有直譯，做了許多刪節，可以視為一份筆記。

感謝Roberto在Lua上的辛勤勞動和付出！