和在所有其他編程語言中一樣，在Lua中，我們依然應當遵循下述兩條有關程序優化的箴言：

原則1：不要做優化。
原則2：暫時不要做優化（對專家而言）。

這兩條原則對于Lua編程來說尤其有意義，Lua正是因其性能而在腳本語言中鶴立雞群。

當然，我們都知道性能是編程中要考量的一個重要因素，指數級時間復雜度的算法會被認為是棘手的問題，絕非偶然。如果計算結果來得太遲，它就是無用的結果。因此，每一個優秀的程序員都應該時刻平衡在優化代碼時所花費的資源和執行代碼時所節省的資源。

優秀的程序員對于代碼優化要提出的第一個問題是：“這個程序需要被優化嗎？”如果（僅當此時）答案是肯定的，第二個問題則是：“在哪里優化？”

要回答這樣兩個問題，我們需要制定一些標準。在進行有效的性能評定之前，不應該做任何優化工作。有經驗的程序員和初學者之前的區別并非在于前者善于指出一個程序的主要性能開銷所在，而是前者知道自己不善于做這件事情。

幾年前，Noemi Rodriguez和我開發了一個用于Lua的CORBA ORB[2]原型，之后演變為OiL。作為第一個原型，我們的實現的目標是簡潔。為防止對額外的C函數庫的依賴，這個原型在序列化整數時使用少量四則運算來分離各個字節（轉換為以256為底），且不支持浮點值。由于CORBA視字符串為字符序列，我們的ORB最初也將Lua字符串轉換為一個字符序列（也就是一個Lua表），并且將其和其他序列等同視之。

當我們完成這個原型之后，我們把它的性能和一個使用C++實現的專業ORB進行對比。由于我們的ORB是使用Lua實現的，預期上我們可以容忍它的速度要慢一些，但是對比結果顯示它慢得太多了，讓我們非常失望。一開始，我們把責任歸結于Lua本身；后來我們懷疑問題出在那些需要序列化整數的操作上。我們使用了一個非常簡單的性能分析器（Profiler），與在《Lua程序設計》[3]第23章里描述的那個沒什么太大差別。出乎我們意料的是，整數序列化并沒有明顯拖慢程序的速度，因為并沒有太多整數需要序列化；反而是序列化字符串需要對低性能負很大責任。實際上，每一條CORBA消息都包含若干個字符串，即使我們沒有顯式地操作字符串亦是如此。而且序列化每一條字符串都是一個性能開銷巨大的工作，因為它需要創建一個新表，并使用單獨的字符填充；然后序列化整個序列，其中需要依次序列化每個字符。一旦我們將字符串序列化作為一種特殊情況（而不是通過通用的序列化流程）重新實現，整個程序的性能就得到了顯著的提升。我們只是添加了幾行代碼，程序的性能已經和C++實現的那個版本有得一拼了[4]。

因此，我們總是應該在優化性能之前進行性能測試。通過測試，才能了解到要優化什么；在優化后再次測試，來確認我們的優化工作確實帶來了性能的提升。

一旦你決定必須優化你的Lua代碼，本文將可能有所幫助。本文描述了一些優化方式，主要是展示在Lua中怎么做會更慢，怎么做又會更快。在這里，我將不會討論一些通用的優化技巧，例如優化算法等等——當然，你應該掌握和使用這些技巧，有很多其他地方可以了解這方面的內容。本文主要討論一些專門針對Lua的優化技巧，與此同時，我還會持續地測試小程序的時間和空間性能。如果沒有特別注明的話，所有的測試都在一臺Pentium IV 2.9GHz、1GB內存、運行Ubuntu 7.10、Lua 5.1.1的機器上進行。我經常會給出實際的測量結果（例如7秒），但是這只在和其他測量數據進行對比時有意義。而當我說一個程序比另一個快X%時，意味著前者比后者少消耗X%的時間（也就是說，比另一個程序快100%的程序的運行不需要時間）；當我說一個程序比另一個慢X%時，則是說后者比前者快X%（意即，比另一個程序慢50%的程序消耗的時間是前者的兩倍）。