Lua性能优化技巧
和在所有其他编程语言中一样,在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%的程序消耗的时间是前者的两倍)。
基本事实
在运行任何代码之前,Lua都会把源代码翻译(预编译)成一种内部的格式。这种格式是一个虚拟机指令序列,与真实的CPU所执行的机器码类似。之后,这个内部格式将会被由一个包含巨大的switch结构的while循环组成的C代码解释执行,switch中的每个case对应一条指令。
可能你已经在别处了解到,从5.0版开始,Lua使用一种基于寄存器的虚拟机。这里所说的虚拟机“寄存器”与真正的CPU寄存器并不相同,因为后者难于移植,而且数量非常有限。Lua使用一个栈(通过一个数组和若干索引来实现)来提供寄存器。每个活动的函数都有一个激活记录,也就是栈上的一个可供该函数存储寄存器的片段。因此,每个函数都有自己的寄存器[1]。一个函数可以使用最多250个寄存器,因为每个指令只有8位用于引用一个寄存器。
由于寄存器数目众多,因此Lua预编译器可以把所有的局部变量都保存在寄存器里。这样带来的好处是,访问局部变量会非常快。例如,如果a和b是局部变量,语句
a = a + b
将只会生成一个指令:
ADD 0 0 1
(假设a和b在寄存器里分别对应0和1)。作为对比,如果a和b都是全局变量,那么这段代码将会变成:
GETGLOBAL 0 0 ; a GETGLOBAL 1 1 ; b ADD 0 0 1 SETGLOBAL 0 0 ; a
因此,可以很简单地得出在Lua编程时最重要的性能优化方式:使用局部变量!
如果你想压榨程序的性能,有很多地方都可以使用这个方法。例如,如果你要在一个很长的循环里调用一个函数,可以预先将这个函数赋值给一个局部变量。比如说如下代码:
for i = 1, 1000000 do local x = math.sin(i) end
比下面这段要慢30%:
local sin = math.sin for i = 1, 1000000 do local x = sin(i) end
访问外部局部变量(或者说,函数的上值)没有直接访问局部变量那么快,但依然比访问全局变量要快一些。例如下面的代码片段:
function foo (x) for i = 1, 1000000 do x = x + math.sin(i) end return x end print(foo(10))
可以优化为在foo外声明一次sin:
local sin = math.sin function foo (x) for i = 1, 1000000 do x = x + sin(i) end return x end print(foo(10))
第二段代码比前者要快30%。
尽管比起其他语言的编译器来说,Lua的编译器非常高效,但是编译依然是重体力活。因此,应该尽可能避免运行时的编译(例如使用loadstring函数),除非你真的需要有如此动态要求的代码,例如由用户输入的代码。只有很少的情况下才需要动态编译代码。
例如,下面的代码创建一个包含返回常数值1到100000的若干个函数的表:
local lim = 10000 local a = {} for i = 1, lim do a[i] = loadstring(string.format("return %d", i)) end print(a[10]()) --> 10
执行这段代码需要1.4秒。
表
一般情况下,你不需要知道Lua实现表的细节,就可以使用它。实际上,Lua花了很多功夫来隐藏内部的实现细节。但是,实现细节揭示了表操作的性能开销情况。因此,要优化使用表的程序(这里特指Lua程序),了解一些表的实现细节是很有好处的。
Lua的表的实现使用了一些很聪明的算法。每个Lua表的内部包含两个部分:数组部分和哈希部分。数组部分以从1到一个特定的n之间的整数作为键来保存元素(我们稍后即将讨论这个n是如何计算出来的)。所有其他元素(包括在上述范围之外的整数键)都被存放在哈希部分里。
正如其名,哈希部分使用哈希算法来保存和查找键。它使用被称为开放地址表的实现方式,意思是说所有的元素都保存在哈希数组中。用一个哈希函数来获取一个键对应的索引;如果存在冲突的话(意即,如果两个键产生了同一个哈希值),这些键将会被放入一个链表,其中每个元素对应一个数组项。当Lua需要向表中添加一个新的键,但哈希数组已满时,Lua将会重新哈希。重新哈希的第一步是决定新的数组部分和哈希部分的大小。因此,Lua遍历所有的元素,计数并对其进行归类,然后为数组部分选择一个大小,这个大小相当于能使数组部分超过一半的空间都被填满的2的最大的幂;然后为哈希部分选择一个大小,相当于正好能容纳哈希部分所有元素的2的最小的幂。
当Lua创建空表时,两个部分的大小都是0。因此,没有为其分配数组。让我们看一看当执行下面的代码时会发生什么:
local a = {} for i = 1, 3 do a[i] = true end
这段代码始于创建一个空表。在循环的第一次迭代中,赋值语句
a[1] = true
触发了一次重新哈希;Lua将数组部分的大小设为1,哈希部分依然为空;第二次迭代时
a[2] = true
触发了另一次重新哈希,将数组部分扩大为2.最终,第三次迭代又触发了一次重新哈希,将数组部分的大小扩大为4。
类似下面的代码
a = {} a.x = 1; a.y = 2; a.z = 3
做的事情类似,只不过增加的是哈希部分的大小。
对于大的表来说,初期的几次重新哈希的开销被分摊到整个表的创建过程中,一个包含三个元素的表需要三次重新哈希,而一个有一百万个元素的表也只需要二十次。但是当创建几千个小表的时候,重新哈希带来的性能影响就会非常显著。
旧版的Lua在创建空表时会预选分配大小(4,如果我没有记错的话),以防止在初始化小表时产生的这些开销。但是这样的实现方式会浪费内存。例如,如果你要创建数百万个点(表现为包含两个元素的表),每个都使用了两倍于实际所需的内存,就会付出高昂的代价。这也是为什么Lua不再为新表预分配数组。
如果你使用C编程,可以通过Lua的API函数lua_createtable来避免重新哈希;除lua_State之外,它还接受两个参数:数组部分的初始大小和哈希部分的初始大小[1]。只要指定适当的值,就可以避免初始化时的重新哈希。需要警惕的是,Lua只会在重新哈希时收缩表的大小,因此如果在初始化时指定了过大的值,Lua可能永远不会纠正你浪费的内存空间。
当使用Lua编程时,你可能可以使用构造式来避免初始化时的重新哈希。当你写下
{true, true, true}
时,Lua知道这个表的数组部分将会有三个元素,因此会创建相应大小的数组。类似的,如果你写下
{x = 1, y = 2, z = 3}
Lua也会为哈希部分创建一个大小为4的数组。例如,执行下面的代码需要2.0秒:
for i = 1, 1000000 do local a = {} a[1] = 1; a[2] = 2; a[3] = 3 end
如果在创建表时给定正确的大小,执行时间可以缩减到0.7秒:
for i = 1, 1000000 do local a = {true, true, true} a[1] = 1; a[2] = 2; a[3] = 3 end
但是,如果你写类似于
{[1] = true, [2] = true, [3] = true}
的代码,Lua还不够聪明,无法识别表达式(在本例中是数值字面量)指定的数组索引,因此它会为哈希部分创建一个大小为4的数组,浪费内存和CPU时间。
两个部分的大小只会在Lua重新哈希时重新计算,重新哈希则只会发生在表完全填满后,Lua需要插入新的元素之时。因此,如果你遍历一个表并清除其所有项(也就是全部设为nil),表的大小不会缩小。但是此时,如果你需要插入新的元素,表的大小将会被调整。多数情况下这都不会成为问题,但是,不要指望能通过清除表项来回收内存:最好是直接把表自身清除掉。
一个可以强制重新哈希的猥琐方法是向表中插入足够多的nil。例如:
a = {} lim = 10000000 for i = 1, lim do a[i] = i end -- 创建一个巨表 print(collectgarbage("count")) --> 196626 for i = 1, lim do a[i] = nil end -- 清除所有元素 print(collectgarbage("count")) --> 196626 for i = lim + 1, 2 * lim do a[i] = nil end -- 创建一堆nil元素 print(collectgarbage("count")) --> 17
除非是在特殊情况下,我不推荐使用这个伎俩:它很慢,并且没有简单的方法能知道要插入多少nil才够。
你可能会好奇Lua为什么不会在清除表项时收缩表。首先是为了避免测试写入表中的内容。如果在赋值时检查值是否为nil,将会拖慢所有的赋值操作。第二,也是最重要的,允许在遍历表时将表项赋值为nil。例如下面的循环:
for k, v in pairs(t) do if some_property(v) then t[k] = nil – 清除元素 end end
如果Lua在每次nil赋值后重新哈希这张表,循环就会被破坏。
如果你想要清除一个表中的所有元素,只需要简单地遍历它:
for k in pairs(t) do t[k] = nil end
一个“聪明”的替代解决方案:
while true do local k = next(t) if not k then break end t[k] = nil end
但是,对于大表来说,这个循环将会非常慢。调用函数next时,如果没有给定前一个键,将会返回表的第一个元素(以某种随机的顺序)。在此例中,next将会遍历这个表,从开始寻找一个非nil元素。由于循环总是将找到的第一个元素置为nil,因此next函数将会花费越来越长的时间来寻找第一个非nil元素。这样的结果是,这个“聪明”的循环需要20秒来清除一个有100,000个元素的表,而使用pairs实现的循环则只需要0.04秒。
通过使用闭包,我们可以避免使用动态编译。下面的代码只需要十分之一的时间完成相同的工作:
function fk (k) return function () return k end end local lim = 100000 local a = {} for i = 1, lim do a[i] = fk(i) end print(a[10]()) --> 10