用好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的做者們，給你們帶來了這麼棒的解決方案！這對中國的遊戲行業也是一次巨大的促進。