《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的作者们，给大家带来了这么棒的解决方案！这对中国的游戏行业也是一次巨大的促进。