circle-loader
by
72/ 0

Luaのボトルネックをすばやくキャッチする方法はありますか? GOT OnlineのLuaレポートを開いて、GOTOnlineの優れた機能を確認しましょう。

ここで、まずレポートページのいくつかのタグを個別に説明します。次に示すように、それらを順番に見ていきましょう。

1.コード効率>> LuaのCPU時間が高い問題

コード効率-CPU時間ページで、Lua側の時間コストを確認できます。

これらの関数をクリックすると、これらの関数の全体のスタック、指定シーンのスタック、および任意フレームのスタックを表示し、ボトルネック関数をすばやく特定できます。

説明:ここに記載されているLuaファイル名/行番号/関数名から、CPU時間にあるボトルネック関数とCPU時間の最大値の具体的な原因を特定できます。

 

Lua関数の命名形式は「X@Y:Z」です。その中には、Xは関数の名前で、取得できない場合、デフォルトのunknownになります。Yは関数が定義されたファイルの場所、Zは関数が定義された行の番号です。Luaスクリプトをバイトコードとして実行する場合、値は常に0になるため、テスト中は可能な限りLuaソースコードを使用して実行することをお勧めします。

 

特に、スタックの分析は逆順表示をサポートしています。多くの場合、スタックを数十層に展開して確認する必要があるため、よく戸惑っています。逆順分析に切り替えると、元のCPU時間スタックが逆順で並べ替えられます。したがって、最大の深層子関数が直接強調表示され、開発チームはコストのボトルネックをすばやく特定することができます。

 

あるプロジェクトを例にして、下図は、順序に沿って、時間コストが高い関数リストです。

スタックを展開してから、高いコストの子関数「Update @ logic / factory / player_builder / hall_player:209」が表示されています。逆序で表示するとどうなりますか?

高いコストの関数がTOPにあるため、この関数から始めましょう

 

 


2.スタックメモリの割り当て>> Luaでのスタックメモリの割り当てが多すぎる問題

Lua GCのトリガー頻度とトリガーコストを減らすため、Luaのスタックメモリ割り当てにも注意してください。レポートでは、スタックメモリの累計割り当て曲線+関数スタックを使用して、スタックメモリ割り当ての原因となった関数を特定します。

 

分析のアイデアは次のとおりです。

1.スタックメモリ割り当ての最大値に注意してください

2.持続的な割り当てに焦点を当てる

各フレームに持続的な割り当てがある場合は、特別な注意を払う必要があります。持続的な割り当てにより、GCが簡単にトリガーされる可能性があります。

3.スタックメモリ割り当ての逆順分析

全体スタック情報では、逆スタック割り当ての割合が高い親ノードに注目して、狙いがあって最適化します。

上の図に示すように、Luaのスタックメモリでは、「逆順」に切り替えることもできます。表示モードを切り替えるだけで、Luaスクリプトのどのコード行が大量のスタックメモリを割り当てているかを直感的に見つけることができます。このようにして、開発チームは、対応するLuaスクリプトを直接開き、その行と関数を直接見つけて変更することができます。


3.Monoオブジェクト参照>>難関のリーク問題

どの種類のLuaプラグインでも、類似なメカニズムがあります。C#層でCacheを維持して、LuaがアクセスしたC#層オブジェクトを参照し、次の問題を防ぎます:LuaでC#オブジェクトに再度アクセスした場合、オブジェクトはC#層のGCによってリサイクルされたかもしれないから、ロジック的なエラーが発生します。したがって、LuaでC#層オブジェクトへの参照を保持すると、オブジェクトが解放されなくなります。そのような参照が増えると、C#層でメモリリークが発生します。

 

ユーザーがこの状況を検知するために、Monoオブジェクトによって参照されるレポートページのCacheに、上記のC#層オブジェクトをまとめ、Cacheに表示されたオブジェクトのタイプと各タイプのオブジェクト総数を統計しました。オブジェクトがUnityEngine.Objectから継承する場合、次の図に示すように、このタイプでDestroyされたオブジェクトの数も統計に入れました。

したがって、Lua参照がMonoリークを引き起こすかどうかを判断する簡単な方法は、Destroyedの総数がゼロかどうかを確認することです。これは、Mono側でDestroyされたが、Lua側でインデックスが付けられている変数の総数を表すため、理論的には0になる傾向があります。次の図に示すように、それが引き続き高い場合、または上昇し続ける傾向がある場合は、リークしている可能性が高くなります。

数が増え続ける一部のタイプのオブジェクトについては、チャートの下の2つの異なるサンプリングポイントでオブジェクト参照を比較して、Lua内の不合理な参照をさらに見つけることもできます。

補足:リークをチェックする必要がある限り、長時間のテストをお勧めします。結局、リーク問題が発生すると、問題がすぐに山積みになっています。

以上はLuaパフォーマンスは最適化する際に注意すべき点である。具体的には、プロジェクトの実際な状況に応じて操作する必要があります。UWAが開発したGOTオンラインとローカルアセットテストは、豊富なテスト機能を提供しており、Lua最適化の助けになれると幸いと存じます。


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com