OStack程序员社区-中国程序员成长平台 › 门户 › 编程› LUA›LUA教程

Lua 性能剖析

原作者: [db:作者] 来自: [db:来源] 收藏邀请

Lua 性能剖析

在这篇文章中：

引言
Lua的基本类型
Table的实现
Table查找性能
Table空间占用对比
虚拟机的主要构造
Lua函数调用的性能
Lua中的全局变量存取
协程切换的性能
垃圾回收
总结
参考资料

引言

Lua语言在游戏行业大受欢迎，因运行效率高(相比于其他脚本语言)，热更方便等原因被广泛应用。在IEG，情况略有不同，C++大行其道。有的小伙伴（包括本文作者）想在现有c++系统中引入lua，被挑战的第一个问题往往是：“Lua性能怎么样？”

一份测试结果显示，C的性能是Lua的30倍，

我们自己也很容易粗略的构建这样的性能对比例子，比如笔者曾经做过的：

分别调用1000万次，lua的执行时间在C代码执行时间的20~40倍之间浮动，基本和Lua慢30倍的结论吻合。

问题来了，Lua为什么这么慢，会不会有些使用不当的坑，踩了以后，连慢30倍都是奢望？怎么使用lua，才能尽可能避开性能缺陷，发挥灵活的长处？

笔者研究了lua 5.3.4的代码，分析lua性能比C慢的原因，对Lua使用过程中可能碰到性能问题和解决方案也有部分阐述。

本文所有的测试都是在Intel Xeon E312xx 2.7G/linux的环境下完成。

Lua的基本类型

粗略的说，lua有8种类型，

nil, boolean, number, string,

function, userdata, thread, table

nil是空类型，表示什么都不是，

number在内部实现中区分为整形和浮点型，

function有三个子类： C Function， Lua Function和light C Function

userdata有两个子类：userdata和light userdata

thread就是lua中的协程

table是lua中唯一的聚合类型，不像c++的STL那样，拥有vector、map、set等多种容器，在lua中，只有table。

这8种类型以union的形式定义在TValue中

typedef union Value {
  GCObject *gc;       /* collectable objects */
  void *p;            /* light userdata */
  int b;              /* booleans */
  lua_CFunction f;    /* light C functions */
  lua_Integer i;      /* integer numbers */
  lua_Number n;       /* float numbers */
} Value;
typedef struct lua_TValue {
   Value value_;          //value具体的数值
   int tt_                //value的类型
} TValue;

nil, boolean, number和lua_CFunction直接存储在TValue中，占用至少12个字节。

string, lua function, userdata, thread和table这些可以被垃圾回收管理的类型，TValue只是索引，具体数据存储在堆上，被gc指针索引。

下面重点介绍table的实现和性能。

Table的实现

Table对外的表现是一个Key-Value的Hash容器，除了nil以外的任意lua基本类型都可以做Key，所有的基本类型都可以做Value。

Table是动态的，随着元素的添加或者回收增长或者缩小。在Lua 4.0之前，Table是严格的按照Hash的方式实现的，后续版本为了提升性能和节省空间， Table内部重构为数组部分和Hash部分两块。

typedef struct Node {
  TValue i_val;     
  TKey i_key;  //包含next
} Node;

数组部分和Hash部分的长度都是2的指数次方，如果需要扩张，就会调用realloc,内存扩张一倍。Hash部分闭散列,发生冲突的时候会在Node数组中寻找一个空闲节点串起来。

数组部分的key为1, 2^n -1,，要求有至少一半的利用率。

a={}
a[10000]="hello,lua"

这上述示例代码中， a表不会把"hello,Lua"放在数组部分，因为利用率太低了，而是把它放在hash部分，10000这个数字作为key。如果后面a表逐渐插入了1到9999的元素， "hello,lua"会在rehash的时候被搬移到数组部分。

默认创建出来的的表，都是空的，在插入元素的过程，逐渐翻倍扩大，从0到1， 1到2，2到4，...都会触发realloc，同时把旧元素拷贝到新申请的空间中，对于最终有成千上万个元素的table，扩张的开销可以接受，但是对于大量生成小的table的场景，会明显拖慢性能，可以通过lua的构造函数，让Lua的编译器预分配空间，比如下面的代码：

Hash部分的扩张也是同样的情形。

Table查找性能

位于数组部分的元素，直接用整数Key做下标到数组中去就可以拿到元素。Hash部分的查找需要经过hash运算和 TValue判等运算，对于lua_number和table/function/userdata, 这都不是问题。对于string，lua做了一点优化。

所有的短字符串(40字节以内)，在Lua内只存储了一份，提前算好了hash值，

Lua内部增加一个string table，这是一个Hash表，所有的短字符串都存储在这里，每次创建一个新的短字符串，都会先到这个表里面查找是否已经存在，如果存在就复用，如果不存在，就在这个表里添加新项。冲突的字符串用链表串起来。

如果string数量超过Hash桶的1/2就把Hash桶数量加倍，然后rehash。

所以短字符串发生Hash值一致时判等只需要比较指针是否相同，这优化了查找，但是增加了创建和回收字符串的成本。

Table空间占用对比

前面分析提到，lua中的基本类型，至少也要占用12个字节。应用程序把从C切换到Lua，内存占用会如何呢？通过下面的比较，大概可以有个结论。

在程序中存储一个多边形的所有的顶点，假定这个多边形有100万个顶点，用3种Lua的表达形式和C做对比：

在上面的例子里，相比于C， Lua消耗的空间增加了5倍也是很正常的事情。很多业务可能对内存增长不敏感，但是在设计时，需要考虑到这个变化。

Lua的基本执行流程

虚拟机的初始化和编译Lua源码一般发生在系统启动初期，对运行时的性能没有影响。本文把分析重点放在虚拟机的运行上。

Lua 5.3.4包含47条虚拟机指令，比如创建一个表（OP_NEWTABLE），执行一次循环（OP_FORLOOP），从表中查找一个元素（OP_GETTABUP）。

可以看出，虚拟指令的功能粒度很粗，主要是为了降低编译器负担，把性能优化的工作交给虚拟机做。

虚拟机的主要构造

typedef struct CallInfo {
  StkId func; 
  StkId top
  struct CallInfo *previous, *next; 
  …
} CallInfo;

global_State把所有可以垃圾回收的对象都串在一个链表里面管理

Lua用一个数据栈和一个调用双向链表(CallInfo)实现了类似C语言中的堆栈的功能。

数据栈是C数组，会动态的增长和回收，不够的时候就realloc，把栈空间扩大一倍。

Lua函数调用会触发数据栈栈顶的增长和CallInfo增加新节点，函数return的时候执行相反的操作。那么Lua函数调用的开销性能如何呢？

Lua函数调用的性能

通过下面的测试代码，对比C和Lua函数调用的开销，可以看出Lua函数调用开销是C的30倍。C代码加O2优化后执行时间不足1ms， gcc编译器已经可以看出测试代码中的调用是没有意义的，自动优化掉了。 Lua编译器远达不到这么好的优化程度。

Lua频繁函数调用一个典型例子就是网络包的编解码。有两种方案可以供对比：

方案1中，C不需要理解数据的描述信息，只提供解码基本类型的函数，由Lua来调用（Lua调用C会引起Lua数据栈和CallInfo的增长和回收）。

TDR是互娱研发部发布的数据描述组件，类似google protobuff。

方案2中， C理解网络包的数据描述信息，然后调用Lua C API（不会引发Lua堆栈的变化）构造最终的解码结果。

两种方案的性能上本质差别在于Lua调用和C调用开销的差别。前面提到，Lua调用性能开销是C的30倍。据某项目的实践，用方案1实现的开销是方案2的30倍左右。

Lua中的全局变量存取

了解了Lua的全局变量存取过程的细节，就会明白为啥全局变量存取性能低下的原因了。

下面的表格对比了全局变量存取和local变量存取的区别：

全局变量涉及的到表的查询和修改，所以性能要显著差于local变量。简单的性能测试也可以看出来。

协程切换的性能

Lua的协程是一个lua_state，有自己的栈和CallInfo，所以协程切换完全没有使用系统相关的调用，如ucontext或者Fiber，实际测试显示，协程的切换cpu消耗和ucontext差不多。测试代码如下：

static ucontext_t uctx_main, uctx_func1;
static void func1(void){
    while(1)   swapcontext(&uctx_func1, &uctx_main);
}  
int main(int argc, char *argv[]){
    char func1_stack[16384];
    getcontext(&uctx_func1);
    uctx_func1.uc_stack.ss_sp = func1_stack;
    uctx_func1.uc_stack.ss_size = sizeof(func1_stack);
    uctx_func1.uc_link = &uctx_main;
    makecontext(&uctx_func1, func1, 0);  
    for(int i = 0; i < 10000000; i++)
         swapcontext(&uctx_main, &uctx_func1);
    exit(EXIT_SUCCESS);
}
c = coroutine.create(function ()
        while true do          
            coroutine.yield()  
        end end)                   
for i = 1, 10000000 do         
    coroutine.resume(c)
end

1000万次的协程切换，ucontext需要4.05秒， lua需要4.33秒，没有显著差异。

垃圾回收

垃圾回收一直默默在后台工作，一般情况下，对使用者是透明的。但是这不意味着垃圾回收的成本是完全可以忽略的。有时候垃圾回收也会严重干扰系统性能。

在Lua 5.0版本中，垃圾回收采用的是双色标记清除算法，

新生成的可垃圾回收对象（后面简称GCObjct， garbage collectable object）都被标记为白色，垃圾回收启动后，会从全局表和Lua栈出发，把所有可以到达的GCObject全部标记为黑色，标记完成后，把所有保持白色的GCObject释放掉，然后把黑色GCObject全部改成白色。

双色标记清除算法简单、高效，但是垃圾回收的过程必须一次性完成，回收时，业务代码必须等待，在一些实时性要求较高的应用场景，比如游戏，并不适用。所以5.0以后的代码采用了三色标记清理算法。

新生成的GCObjct都被标记为白色，垃圾收集阶段，先把根节点置成灰色，然后遍历灰色GCObject链表，如果灰色节点的所有1级子节点都被放入了灰色链表，就把这个灰色节点置黑，反复遍历灰色链表，直到灰色链表为空。接下来就和双色算法类似了，清理白色节点，然后把黑色重新变白。

三色算法的优点在于，算法是可以分步慢慢执行的，不需要像二色算法那样一下子占用太多的cpu时间。如果在垃圾回收的过程中，发生了白色节点加入到了黑色节点的操作，要么把白色节点变成灰色，要么把黑色节点变成灰色。

查阅代码可以看到，垃圾回收操作触发时机是在执行虚拟指令OP_NEWTABLE 、OP_CONCAT、 OP_CLOSURE的时候，简言之，就是系统分配内存的时候可能会触发垃圾回收

collectgarbage函数可以强制Lua单次完成垃圾回收的全过程，通过下面的测试代码，可以窥视一下垃圾回收的消耗。假定1个Player有10个属性，50个物品，每个物品有10个属性，控制player的数量，测试垃圾回收的消耗。

player={}
player.name="abc"..math.random()
player.level = 10  player.faceid=3 player.hp = 1000               
player.mp = 1000 player.headid = 3  player.gender = 3              
player.money = 30000   player.hornor = 300  player.pk = 300                
player.itemlist = {}           
for j=1, 50  do                             
    item={}                    
    item.attr1="red"    item.attr2=5    item.attr3=1
    item.attr4=1    item.attr5=5    item.attr6=5              
    item.attr7=1    item.attr8=1    item.attr9=1  item.attr10=1      
    player.itemlist[j]=item 
end