前言
Lua是一門以其性能著稱的腳本語言，被廣泛應用在很多方面，尤其是游戲。像《魔獸世界》的插件，手機游戲《大掌門》《神曲》《迷失之地》等都是用Lua來寫的邏輯。
所以大部分時候我們不需要去考慮性能問題。Knuth有句名言：“過早優(yōu)化是萬惡之源”。其意思就是過早優(yōu)化是不必要的，會浪費大量時間，而且容易導致代碼混亂。
所以一個好的程序員在考慮優(yōu)化性能前必須問自己兩個問題：“我的程序真的需要優(yōu)化嗎？”。如果答案為是，那么再問自己：“優(yōu)化哪個部分？”。
我們不能靠臆想和憑空猜測來決定優(yōu)化哪個部分，代碼的運行效率必須是可測量的。我們需要借助于分析器來測定性能的瓶頸，然后著手優(yōu)化。優(yōu)化后，我們仍然要借助于分析器來測量所做的優(yōu)化是否真的有效。
我認為最好的方式是在首次編寫的時候按照最佳實踐去寫出高性能的代碼，而不是編寫了一堆垃圾代碼后，再考慮優(yōu)化。相信工作后大家都會對事后的優(yōu)化的繁瑣都深有體會。
一旦你決定編寫高性能的Lua代碼，下文將會指出在Lua中哪些代碼是可以優(yōu)化的，哪些代碼會是運行緩慢的，然后怎么去優(yōu)化它們。
使用local
在代碼運行前，Lua會把源碼預編譯成一種中間碼，類似于Java的虛擬機。這種格式然后會通過C的解釋器進行解釋，整個過程其實就是通過一個while循環(huán)，里面有很多的switch...case語句，一個case對應一條指令來解析。
自Lua 5.0之后，Lua采用了一種類似于寄存器的虛擬機模式。Lua用棧來儲存其寄存器。每一個活動的函數(shù)，Lua都會其分配一個棧，這個棧用來儲存函數(shù)里的活動記錄。每一個函數(shù)的棧都可以儲存至多250個寄存器，因為棧的長度是用8個比特表示的。
有了這么多的寄存器，Lua的預編譯器能把所有的local變量儲存在其中。這就使得Lua在獲取local變量時其效率十分的高。
舉個栗子： 假設a和b為local變量，a = a + b的預編譯會產生一條指令：
1
2;a是寄存器0b是寄存器1
ADD001
但是若a和b都沒有聲明為local變量，則預編譯會產生如下指令：
1
2
3
4GETGLOBAL00;geta
GETGLOBAL11;getb
ADD001;doadd
SETGLOBAL00;seta
所以你懂的：在寫Lua代碼時，你應該盡量使用local變量。
以下是幾個對比測試，你可以復制代碼到你的編輯器中，進行測試。
1
2
3
4
5
6a=os.clock()
fori=1,10000000do
localx=math.sin(i)
end
b=os.clock()
print(b-a)--1.113454
把math.sin賦給local變量sin：
1
2
3
4
5
6
7a=os.clock()
localsin=math.sin
fori=1,10000000do
localx=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底層是如何實現(xiàn)表，對我們編寫Lua代碼是有好處的。
Lua的表分為兩個部分：數(shù)組(array)部分和哈希(hash)部分。數(shù)組部分包含所有從1到n的整數(shù)鍵，其他的所有鍵都儲存在哈希部分中。
哈希部分其實就是一個哈希表，哈希表本質是一個數(shù)組，它利用哈希算法將鍵轉化為數(shù)組下標，若下標有沖突(即同一個下標對應了兩個不同的鍵)，則它會將沖突的下標上創(chuàng)建一個鏈表，將不同的鍵串在這個鏈表上，這種解決沖突的方法叫做：鏈地址法。
當我們把一個新鍵值賦給表時，若數(shù)組和哈希表已經滿了，則會觸發(fā)一個再哈希(rehash)。再哈希的代價是高昂的。首先會在內存中分配一個新的長度的數(shù)組，然后將所有記錄再全部哈希一遍，將原來的記錄轉移到新數(shù)組中。新哈希表的長度是最接近于所有元素數(shù)目的2的乘方。
當創(chuàng)建一個空表時，數(shù)組和哈希部分的長度都將初始化為0，即不會為它們初始化任何數(shù)組。讓我們來看下執(zhí)行下面這段代碼時在Lua中發(fā)生了什么：
1
2
3
4locala={}
fori=1,3do
a[i]=true
end
最開始，Lua創(chuàng)建了一個空表a，在第一次迭代中，a[1] = true觸發(fā)了一次rehash，Lua將數(shù)組部分的長度設置為2^0，即1，哈希部分仍為空。在第二次迭代中，a[2] = true再次觸發(fā)了rehash，將數(shù)組部分長度設為2^1，即2。最后一次迭代，又觸發(fā)了一次rehash，將數(shù)組部分長度設為2^2，即4。
下面這段代碼：
1
2a={}
a.x=1;a.y=2;a.z=3
與上一段代碼類似，只是其觸發(fā)了三次表中哈希部分的rehash而已。
只有三個元素的表，會執(zhí)行三次rehash；然而有一百萬個元素的表僅僅只會執(zhí)行20次rehash而已，因為2^20 = 1048576 > 1000000。但是，如果你創(chuàng)建了非常多的長度很小的表（比如坐標點：point = {x=0,y=0}），這可能會造成巨大的影響。
如果你有很多非常多的很小的表需要創(chuàng)建時，你可以將其預先填充以避免rehash。比如：{true,true,true}，Lua知道這個表有三個元素，所以Lua直接創(chuàng)建了三個元素長度的數(shù)組。類似的，{x=1, y=2, z=3}，Lua會在其哈希部分中創(chuàng)建長度為4的數(shù)組。
以下代碼執(zhí)行時間為1.53秒：
1
2
3
4
5
6
7a=os.clock()
fori=1,2000000do
locala={}
a[1]=1;a[2]=2;a[3]=3
end
b=os.clock()
print(b-a)--1.528293
如果我們在創(chuàng)建表的時候就填充好它的大小，則只需要0.75秒，一倍的效率提升！
1
2
3
4
5
6
7a=os.clock()
fori=1,2000000do
locala={1,1,1}
a[1]=1;a[2]=2;a[3]=3
end
b=os.clock()
print(b-a)--0.746453
所以，當需要創(chuàng)建非常多的小size的表時，應預先填充好表的大小。
關于字符串
與其他主流腳本語言不同的是，Lua在實現(xiàn)字符串類型有兩方面不同。
第一，所有的字符串在Lua中都只儲存一份拷貝。當新字符串出現(xiàn)時，Lua檢查是否有其相同的拷貝，若沒有則創(chuàng)建它，否則，指向這個拷貝。這可以使得字符串比較和表索引變得相當?shù)目欤驗楸容^字符串只需要檢查引用是否一致即可；但是這也降低了創(chuàng)建字符串時的效率，因為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秒：
1
2
3
4
5
6
7a=os.clock()
locals=''
fori=1,300000do
s=s..'a'
end
b=os.clock()
print(b-a)--6.649481
我們可以用table來模擬buffer，下面的代碼只需花費0.72秒，9倍多的效率提升：
1
2
3
4
5
6
7
8
9a=os.clock()
locals=''
localt={}
fori=1,300000do
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）和再循環(huán)（recycling）三種原則的簡稱。
3R原則本是循環(huán)經濟和環(huán)保的原則，但是其同樣適用于Lua。
Reducing
有許多辦法能夠避免創(chuàng)建新對象和節(jié)約內存。例如：如果你的程序中使用了太多的表，你可以考慮換一種數(shù)據結構來表示。
舉個栗子。 假設你的程序中有多邊形這個類型，你用一個表來儲存多邊形的頂點：
1
2
3
4
5
6polyline={
{x=1.1,y=2.9},
{x=1.1,y=3.7},
{x=4.6,y=5.2},
...
}
以上的數(shù)據結構十分自然，便于理解。但是每一個頂點都需要一個哈希部分來儲存。如果放置在數(shù)組部分中，則會減少內存的占用:
1
2
3
4
5
6polyline={
{1.1,2.9},
{1.1,3.7},
{4.6,5.2},
...
}
一百萬個頂點時，內存將會由153.3MB減少到107.6MB，但是代價是代碼的可讀性降低了。
最變態(tài)的方法是：
1
2
3
4polyline={
x={1.1,1.1,4.6,...},
y={2.9,3.7,5.2,...}
}
一百萬個頂點，內存將只占用32MB，相當于原來的1/5。你需要在性能和代碼可讀性之間做出取舍。
在循環(huán)中，我們更需要注意實例的創(chuàng)建。
1
2
3
4
5fori=1,ndo
localt={1,2,3,'hi'}
--執(zhí)行邏輯，但t不更改
...
end
我們應該把在循環(huán)中不變的東西放到循環(huán)外來創(chuàng)建：
1
2
3
4
5localt={1,2,3,'hi'}
fori=1,ndo
--執(zhí)行邏輯，但t不更改
...
end
Reusing
如果無法避免創(chuàng)建新對象，我們需要考慮重用舊對象。
考慮下面這段代碼：
1
2
3
4localt={}
fori=1970,2000do
t[i]=os.time({year=i,month=6,day=14})
end
在每次循環(huán)迭代中，都會創(chuàng)建一個新表{year = i, month = 6, day = 14}，但是只有year是變量。
下面這段代碼重用了表：
1
2
3
4
5
6localt={}
localaux={year=nil,month=6,day=14}
fori=1970,2000do
aux.year=i;
t[i]=os.time(aux)
end
另一種方式的重用，則是在于緩存之前計算的內容，以避免后續(xù)的重復計算。后續(xù)遇到相同的情況時，則可以直接查表取出。這種方式實際就是動態(tài)規(guī)劃效率高的原因所在，其本質是用空間換時間。
Recycling
Lua自帶垃圾回收器，所以我們一般不需要考慮垃圾回收的問題。
了解Lua的垃圾回收能使得我們編程的自由度更大。
Lua的垃圾回收器是一個增量運行的機制。即回收分成許多小步驟（增量的）來進行。
頻繁的垃圾回收可能會降低程序的運行效率。
我們可以通過Lua的collectgarbage函數(shù)來控制垃圾回收器。
collectgarbage函數(shù)提供了多項功能：停止垃圾回收，重啟垃圾回收，強制執(zhí)行一次回收循環(huán)，強制執(zhí)行一步垃圾回收，獲取Lua占用的內存，以及兩個影響垃圾回收頻率和步幅的參數(shù)。
對于批處理的Lua程序來說，停止垃圾回收collectgarbage("stop")會提高效率，因為批處理程序在結束時，內存將全部被釋放。
對于垃圾回收器的步幅來說，實際上很難一概而論。更快幅度的垃圾回收會消耗更多CPU，但會釋放更多內存，從而也降低了CPU的分頁時間。只有小心的試驗，我們才知道哪種方式更適合。
結語
我們應該在寫代碼時，按照高標準去寫，盡量避免在事后進行優(yōu)化。
如果真的有性能問題，我們需要用工具量化效率，找到瓶頸，然后針對其優(yōu)化。當然優(yōu)化過后需要再次測量，查看是否優(yōu)化成功。
在優(yōu)化中，我們會面臨很多選擇：代碼可讀性和運行效率，CPU換內存，內存換CPU等等。需要根據實際情況進行不斷試驗，來找到最終的平衡點。
最后，有兩個終極武器：
第一、使用LuaJIT，LuaJIT可以使你在不修改代碼的情況下獲得平均約5倍的加速。查看LuaJIT在x86/x64下的性能提升比。
第二、將瓶頸部分用C/C++來寫。因為Lua和C的天生近親關系，使得Lua和C可以混合編程。但是C和Lua之間的通訊會抵消掉一部分C帶來的優(yōu)勢。
注意：這兩者并不是兼容的，你用C改寫的Lua代碼越多，LuaJIT所帶來的優(yōu)化幅度就越小。
聲明
這篇文章是基于Lua語言的創(chuàng)造者Roberto Ierusalimschy在Lua Programming Gems中的Lua Performance Tips翻譯改寫而來。本文沒有直譯，做了許多刪節(jié)，可以視為一份筆記。
感謝Roberto在Lua上的辛勤勞動和付出！
