用好lua+unity，让性能飞起来——关于《Unity项目常见Lua解决方案性能比较》的一些补充

《Unity项目常见Lua解决方案性能比较》，这篇文章对比了如今主流几个lua+unity的方案

http://blog.uwa4d.com/archives/lua_perf.html

 

 

事实上2015年slua做者就发起过这个性能对比，当时这个对比还引起过一些口水战，具体可见ulua的官网

这里并不是比较各类lua+unity的方案的优劣，事实上各个方案都进化到静态导出的方案，性能不会有质的差异。这里是但愿经过分析用例背后的原理和细节，发现这些测试为什么会产生这样的结果，以及对应方案背后有什么特色，如何进一步优化。不少的benchmark，数据是真的，可是若是不知道背后的缘由，则可能在结论上有误导性，由于你并不知道问题出在哪里，可能一个小小的改动或者测试用例设计不合理就会致使结果巨大的差别。

 

test1/test2：

在《lua和c#交互篇》咱们也模仿了test1作了一个测试，不过由于考虑到直接使用unity的transform会产生一些来自unity内部的消耗（c#到c导出消耗、unity刷新transform的消耗），致使结果不能彻底反映lua自己的导出性能，因此咱们的测试方式是本身实现了一个新的Transform并基于此作测试。test2也是通用存在这样的问题。

 

test3/test6：

在slua的测试里也有test3这个用例，但slua做者认为这个测试的是静态函数调用，这点有必定的问题，由于无论slua仍是ulua，Vector3都是纯lua代码的实现，并无走c#，也谈不上测试静态函数导出的性能了（只能说测试了Vector3.Normalize实现的性能）。

另外在uwa给出的数据中，咱们会发现S3测出的ulua数据十分不正常（比其余两个lua方案高出上百倍），由于前面说过Vector3是纯lua代码实现，对比ulua和slua的代码也会发现Vector3.Normalize的实现并无很大的差别，咱们认为这是触发了咱们在luajit集成篇提到的jit失败致使的，尤为极有多是机器码内存分配失败的bug，在出现这个bug的状况下，运行速度降低百倍是常有的事情。

 

test4：

这个是测试GameObject的构造性能，其中lua与C#交互的流程并不复杂，仅仅就是经过metatable调用new GameObject而后返回到lua中，因此主要的消耗应该是来自于GameObject建立自己，至于为何ios设备下广泛耗时比其余用例要长，咱们认为是il2cpp致使的。

 

 

 

最后总结一下

若是是纯粹测试lua导出c#的性能，那么最好的办法是使用本身的c#代码导出，而规避使用unity自己的对象的导出，由于可能会引入不少unity自己的性能干扰。

用例自己尽量不要引入过多的非语言因素的性能消耗（好比Vector3.Normalize，自己的计算量消耗比调用消耗还大得多）。

luajit的行为过于复杂，其性能测试在安卓平台下十分不稳定，这一点是一个大坑（详见《luajit集成篇》）

 

 

最后感谢ulua、slua、cstolua的做者们，给你们带来了这么棒的解决方案！这对中国的游戏行业也是一次巨大的促进。