XLua下的Lua与C#传值优化

前言

Unity下的C#GC Alloc（下面简称gc）是个大问题，而嵌入一个动态类型的Lua后，它们之间的交互很容易就产生gc，各种Lua方案也把这作为性能优化的重点。这些优化说穿了其实不复杂。

元凶在这里
先看看这两个函数

int inc1(int i)
{
    return i + 1;
}
 
object inc2(object o)
{
    return (int)o + 1;
}

window下实测inc1的性能是inc2的20倍！

差距为什么那么大？主要原因在其参数及返回的类型，inc2参数是object类型，意味着一个值类型传入（比如整数）需要boxing，具体一点就是在堆上申请一块内存，把类型信息，值拷贝进去，要使用的时候需要unboxing，也就是从刚刚那堆内存拷贝到栈上，等函数执行完毕后，这个堆内存被gc检测到已经没引用，释放该堆内存。

20倍差距是一个参数一个返回的情况，随着这样的参数加多，差距更大。而且更糟糕的是：GC比较难控制，Unity的手游项目，GC往往是卡顿的元凶。

目前所有lua方案针对lua和c#间交互的gc优化，或者值类型优化，其实都是在做一件事：避免inc2的情况。

C#调用Lua避免inc2
Lua是一门动态类型语言，它的函数可以接受任意类型，任意个数的参数，返回值也是任意类型，任意个数。如果希望以一个通用接口去访问lua函数，情况会比inc2更糟糕：为了支持任意类型任意个数参数，我们可能得用可变参数；为了支持任意类型多返回值，这个接口可能需要返回一个object数组，而不是一个object。因而我们还多了两个数组要分配及释放。函数原型大致如下：

object[]Call(params object[] args)

因为以上原因，大多方案虽然都提供了这种方式（因为方便），但又不推荐使用。有的方案会提供无GC的用法，例如ulua如果要避免gc，得这么来：

var func = lua.GetFunction("inc");  
func.BeginPCall();
func.Push(123456);
func.PCall();
int num = (int)func.CheckNumber();
func.EndPCall();
思路是把lua的栈操作api暴露出来，一个个参数的压栈，调用完一个个返回值的取。这些压栈和取返回值的接口都是确定类型的，换句话也就是inc1的接口。

上面只是单参数，单返回值的情况，大多数情况代码会更繁琐。

而slua没有找到相关的方案。

 

xLua的解决办法的核心思想是：只要你告诉我要用什么参数调用，我帮你优化。

[CSharpCallLua]
public delegate int Inc(int i);
Inc func= luaenv.Global.Get("inc");
int num =  func(123456);
1、按你所需声明一个delegate，打上CSharpCallLua标签；

2、执行生成代码；

3、用Table的Get接口把inc函数映射到func委托；

4、接下来就可以愉快的使用这个delegate了。

多复杂的参数都是和上面一样：声明，获取，使用。仅比带gc的Call接口多了一步声明，使用上和Call接口一样简单，甚至处理返回值方面更简单些，而且还额外带来强类型检查的好处。

如果lua函数有多个返回值怎么办？

多返回值将会映射到C#的返回值以及各输出参数，从左往右一一映射。

除此之外，xLua还支持一个lua table映射到一个C# interface，对这个interface的属性访问会访问到lua table的对应字段，成员方法调用会调用到lua table里头的对应函数。同样的，无gc。

这是如何做到的呢？说起来也不复杂，以lua函数映射到c# delegate为例，xLua会对声明了CSharpCallLua的delegate生成一段代码，比如Inc的生成代码会类似这样：

public int SystemInt32(int x)
{
    //...init
    LuaAPI.lua_getref(L, _Reference);
              
    LuaAPI.xlua_pushinteger(L, x);
    int __gen_error = LuaAPI.lua_pcall(L, 1, 1, err_func);
 
    //...error handle
    int __gen_ret = LuaAPI.xlua_tointeger(L, err_func + 1);
    LuaAPI.lua_settop(L, err_func - 1);
    return  __gen_ret;
}

Get方法返回的委托将会指向这个方法。从这段代码来看，和ulua无gc代码类似，不同的是，别人家得手写，而且由于xLua少了一层封装，直接调用Lua的api，应该也更高效些。

 

复杂值类型优化

从C#到lua的复杂对象传递说起

lua虚拟机，对于.net就是非托管代码，要传递对象过去，得解决几个问题：

1、lua使用该对象期间，该对象不能被gc；

2、如果非托管代码（lua）回调托管代码（c#），当回传该对象的引用时，应该正确找到对应的对象；

3、重复传递一个对象，在unmanaged code测的引用表示最好是一致的；

问题1和问题2 官方给的方案是pined对象，实测pined一个对象以及释放的性能大致和Dictionary的Set/Get相当，而问题1和问题2可以优化为数组操作，性能可以比Pined方案高4~5倍：接受一个对象，在一个数组上找到一个空位置放进去，返回数组的下标作为对象引用。通过链表组织空位置，空位置查找可以优化成O（1）操作，而通过引用找对象当然也是O（1）。

问题3没啥好的解决办法，用Dictionary建立对象到引用的索引。

 

复杂值类型的困境

C#一切都是对象，自然也包括值类型，也能沿用上面的方案，这功能上没问题，性能却遭遇了滑铁卢：

每一次值类型放入对象池（指的是前面一节中提到的为了解决3个问题而做的一套机制）中就会碰到inc2的情况，会boxing成一个新对象，还有入池的一系列操作。有人会问用pined方案会不会没这问题，其实是一样的，值类型是在栈上，而pined了之后要从栈转到堆上，栈转堆还是会有类似的过程：分配堆内存，拷贝，用完释放。

这问题比前面那问题影响面更广，只要C#往lua传递一个复杂值类型就会出现，比如普普通通的Vector3四则运算会产生大量的gc。

ulua和slua思路是一样的，对特定的几个U3D值类型（Vector2， Vector3，Vector4，Quaternion）做硬编码优化，以Vector3为例：

1、用lua重新实现了Vector3的所有方法；

2、C#的Vector3传入lua：是先在lua侧建一个luatable，把待传入Vector3的x，y，z设置为对应字段；设置该table的metatable为1的方法实现；

3、lua回传Vector3到C#：C#构建一个Vector3后，取出对应table的x，y，z字段赋值到Vector3；

xLua的复杂值类型优化

上面的优化存在一些问题：需要增加一种新的值类型十分困难，所以目前为止采用这种方案能支持的值类型手指头就能数得过来，用户自定义的struct就更不可能支持了，核心代码深度耦合这几个类型也是不合理的。还有个比较严重的问题：xLua作者比较抗拒硬编码这种行为。

让我们思考一下，ulua和slua那种优化能避免gc的本质是什么？还有简单值类型从C#传递到lua也没产生gc，原因是什么？

答案就是：值拷贝！

ulua和slua的复杂值类型优化，从C#传递到lua本质上是把Vector3值拷贝到lua table，避免了入池进而避免了inc2；简单值类型也是，一个c#的int传入lua，也是直接把int值拷贝到lua的栈上。

明白了这个思路就开阔很多，xLua设计了一套新的值类型方案，只要一个struct里头只包含值类型，可嵌套struct，当然，要求被嵌套的struct也只包含值类型，该方法都适用。

原理也不复杂：

1、生成struct的值拷贝代码，用于把struct里头各字段拷贝到一块非托管内存（Pack函数），以及从非托管内存拷贝出各字段的值（UnPack函数）；

2、c#传struct到lua：调用lua的api，申请一块userdata（对于c#来说是非托管代码），调用Pack把struct打包进去；

3、lua回传到给c#：调用UnPack解出struct；

4、struct的方法还是沿用c#原本的实现；

说穿了，就和pb类似，把c#的数据结构序列化到一块内存以及从内存反序列化回来。

先说这方案的缺点：

缺点源于这个方案调用struct的方法还是调用原来C#的实现。从lua经C语言，再经pinvoke调用到C#，这个适配的成本已经远远大于一些简单方法执行的开销。当然，xLua只是默认调用C#的实现，也不是必须的，xLua提供了不经过C#，在C就直接读取更改struct字段的API，比较勤快的童鞋利用这API，可以尝试把需要高性能的地方用Lua实现，这就避免了lua和C#间的适配成本。

PS一下：网上很流行的lua方案性能用例，用Vector3.Normalize来测试lua调用c#静态函数的性能，甚至Unity官方发的测评都用这个用例。由前面的分析可以知道，这是不对的，这些被测方案的Vector3.Normalize都仅在lua里头跑，压根没测试到“lua调用c#静态函数”。

这方案优点：

1、支持的struct类型宽泛的多，用户要做的事情也很简单，声明一下要生成代码即可（GCOptimize），之所以要声明，主要是避免生成代码过多；

2、相比table方案更省内存，只是struct的大小加上一个头部，而64位下空table就80字节+，实际测试Vector3的userdata方案的内存占用是table方案三分之一；

其它值类型GC优化
下面大多数优化都只在xLua有效，可以在其05_NoGc示例看到用法，生成代码后运行在profiler看你效果。

1、枚举类型传递无GC；

2、decimal不丢失精度而且无GC；

3、所有无GC的类型，它的数组访问没有GC，这个貌似大多数方案都做到；

4、能被GCOptimize优化的struct，在Lua可以直接传一个对应结构的table，无GC；

5、LuaTable提供一系列泛化Get/Set接口，可以传递值类型而无GC；

6、一个interface加入到CSharpCallLua后，可以用table来实现这个interface，通过这interface访问table无GC；

这些优化和前面介绍的两大思路一脉相承，可以通过源代码看其实现，这就不分析了。