《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的作者們，給大家帶來了這么棒的解決方案！這對中國的游戲行業也是一次巨大的促進。