編寫高性能的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的預編譯會產生一條指令：

0 1	;a是寄存器0 b是寄存器1 ADD 0 0 1

可是若a和b都沒有聲明爲local變量，則預編譯會產生以下指令：

0 1 2 3

GETGLOBAL    0 0    ;get a GETGLOBAL    1 1    ;get b ADD          0 0 1  ;do add SETGLOBAL    0 0    ;set a

因此你懂的：在寫Lua代碼時，你應該儘可能使用local變量。

如下是幾個對比測試，你能夠複製代碼到你的編輯器中，進行測試。

0 1 2 3 4 5

a = os.clock() for i = 1,10000000 do   local x = math.sin(i) end b = os.clock() print(b-a) --1.113454

把math.sin賦給local變量sin：

0 1 2 3 4 5 6

a = os.clock() local sin = math.sin for i = 1,10000000 do   local x = sin(i) end b = os.clock() print(b-a) --0.75951

直接使用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中發生了什麼：

0 1 2 3

local a = {} for i=1,3 do     a[i] = true end

最開始，Lua建立了一個空表a，在第一次迭代中，a[1] = true觸發了一次rehash，Lua將數組部分的長度設置爲2^0，即1，哈希部分仍爲空。在第二次迭代中，a[2] = true再次觸發了rehash，將數組部分長度設爲2^1，即2。最後一次迭代，又觸發了一次rehash，將數組部分長度設爲2^2，即4。

下面這段代碼：

0 1	a = {} a.x = 1; a.y = 2; a.z = 3

與上一段代碼相似，只是其觸發了三次表中哈希部分的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 1 2 3 4 5 6

a = os.clock() for i = 1,2000000 do     local a = {}     a[1] = 1; a[2] = 2; a[3] = 3 end b = os.clock() print(b-a)  --1.528293

若是咱們在建立表的時候就填充好它的大小，則只須要0.75秒，一倍的效率提高！

0 1 2 3 4 5 6

a = os.clock() for i = 1,2000000 do     local a = {1,1,1}     a[1] = 1; a[2] = 2; a[3] = 3 end b = os.clock() print(b-a)  --0.746453

因此，當須要建立很是多的小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秒：

0 1 2 3 4 5 6

a = os.clock() local s = '' for i = 1,300000 do     s = s .. 'a' end b = os.clock() print(b-a)  --6.649481

咱們能夠用table來模擬buffer，下面的代碼只需花費0.72秒，9倍多的效率提高：

0 1 2 3 4 5 6 7 8

a = os.clock() local s = '' local t = {} for i = 1,300000 do     t[#t + 1] = 'a' end s = table.concat( t, '') b = os.clock() print(b-a)  --0.07178

因此：在大字符串鏈接中，咱們應避免..。應用table來模擬buffer，而後concat獲得最終字符串。

3R原則

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

3R原則本是循環經濟和環保的原則，可是其一樣適用於Lua。

Reducing

有許多辦法可以避免建立新對象和節約內存。例如：若是你的程序中使用了太多的表，你能夠考慮換一種數據結構來表示。

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

0 1 2 3 4 5

polyline = {     { x = 1.1, y = 2.9 },     { x = 1.1, y = 3.7 },     { x = 4.6, y = 5.2 },     ... }

以上的數據結構十分天然，便於理解。可是每個頂點都須要一個哈希部分來儲存。若是放置在數組部分中，則會減小內存的佔用:

0 1 2 3 4 5

polyline = {     { 1.1, 2.9 },     { 1.1, 3.7 },     { 4.6, 5.2 },     ... }

一百萬個頂點時，內存將會由153.3MB減小到107.6MB，可是代價是代碼的可讀性下降了。

最變態的方法是：

0 1 2 3

polyline = {     x = {1.1, 1.1, 4.6, ...},     y = {2.9, 3.7, 5.2, ...} }

一百萬個頂點，內存將只佔用32MB，至關於原來的1/5。你須要在性能和代碼可讀性之間作出取捨。

在循環中，咱們更須要注意實例的建立。

0 1 2 3 4

for i=1,n do     local t = {1,2,3,'hi'}     --執行邏輯，但t不更改     ... end

咱們應該把在循環中不變的東西放到循環外來建立：

0 1 2 3 4

local t = {1,2,3,'hi'} for i=1,n do     --執行邏輯，但t不更改     ... end

Reusing

若是沒法避免建立新對象，咱們須要考慮重用舊對象。

考慮下面這段代碼：

0 1 2 3

local t = {} for i = 1970, 2000 do     t[i] = os.time({year = i, month = 6, day = 14}) end

在每次循環迭代中，都會建立一個新表{year = i, month = 6, day = 14}，可是隻有year是變量。

下面這段代碼重用了表：

0 1 2 3 4 5

local t = {} local aux = {year = nil, month = 6, day = 14} for i = 1970, 2000 do     aux.year = i;     t[i] = os.time(aux) end

另外一種方式的重用，則是在於緩存以前計算的內容，以免後續的重複計算。後續遇到相同的狀況時，則能夠直接查表取出。這種方式實際就是動態規劃效率高的緣由所在，其本質是用空間換時間。

Recycling

Lua自帶垃圾回收器，因此咱們通常不須要考慮垃圾回收的問題。

瞭解Lua的垃圾回收能使得咱們編程的自由度更大。

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

頻繁的垃圾回收可能會下降程序的運行效率。

咱們能夠經過Lua的collectgarbage函數來控制垃圾回收器。

collectgarbage函數提供了多項功能：中止垃圾回收，重啓垃圾回收，強制執行一次回收循環，強制執行一步垃圾回收，獲取Lua佔用的內存，以及兩個影響垃圾回收頻率和步幅的參數。

對於批處理的Lua程序來講，中止垃圾回收collectgarbage("stop")會提升效率，由於批處理程序在結束時，內存將所有被釋放。

對於垃圾回收器的步幅來講，實際上很難一律而論。更快幅度的垃圾回收會消耗更多CPU，但會釋放更多內存，從而也下降了CPU的分頁時間。只有當心的試驗，咱們才知道哪一種方式更適合。

結語

咱們應該在寫代碼時，按照高標準去寫，儘可能避免在過後進行優化。

若是真的有性能問題，咱們須要用工具量化效率，找到瓶頸，而後針對其優化。固然優化事後須要再次測量，查看是否優化成功。

在優化中，咱們會面臨不少選擇：代碼可讀性和運行效率，CPU換內存，內存換CPU等等。須要根據實際狀況進行不斷試驗，來找到最終的平衡點。

最後，有兩個終極武器：

第1、使用LuaJIT，LuaJIT可使你在不修改代碼的狀況下得到平均約5倍的加速。查看LuaJIT在x86/x64下的性能提高比。

第2、將瓶頸部分用C/C++來寫。由於Lua和C的天生近親關係，使得Lua和C能夠混合編程。可是C和Lua之間的通信會抵消掉一部分C帶來的優點。

注意：這二者並非兼容的，你用C改寫的Lua代碼越多，LuaJIT所帶來的優化幅度就越小。

聲明

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

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