和在所有其他編程語言中一樣，在Lua中，我們依然應(yīng)當(dāng)遵循下述兩條有關(guān)程序優(yōu)化的箴言：

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

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

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

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

要回答這樣兩個問題，我們需要制定一些標(biāo)準(zhǔn)。在進(jìn)行有效的性能評定之前，不應(yīng)該做任何優(yōu)化工作。有經(jīng)驗的程序員和初學(xué)者之前的區(qū)別并非在于前者善于指出一個程序的主要性能開銷所在，而是前者知道自己不善于做這件事情。

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

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

因此，我們總是應(yīng)該在優(yōu)化性能之前進(jìn)行性能測試。通過測試，才能了解到要優(yōu)化什么；在優(yōu)化后再次測試，來確認(rèn)我們的優(yōu)化工作確實帶來了性能的提升。

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

最新評論