処理時間測定その3--Deepでフリーズ

かおもさんよりヒントを頂きました
「 EngineFacade.Update がCSEでのUpdate1回分
  CodeRunner.Update jsファイル1個分
これでscriptの処理時間が測定できそうです
そもそも Deep profile mode を使う手順を知りませんでした
恥ずかしい~~
さっそく体験記を追記しておきます
2024.0331 更新

手順E DeepProfileオンの場合----------------------------------

手順AにDeepProfileオンを加味します    前回の手順Aを参照のこと

今回の実験データはscript付きitemを20数個に複製し
script負荷を強調したものです 
省略されていたブロックも全部表示されるらしく 印象が変わります
測定前にオンにしないと効果がないようです
画面では Deep profile mode の灰色がオンかオフか見分けにくいですね
Timelineの階層が増えて さらに複雑になっています
見慣れないアルファベットがびっしりで拒否反応が起きるところです
ここまで深入りしたくなかったというヒトもいるでしょう
ヒントの [EngineFacade.Update]のブロックを探します 
timelineでは 探しにくいので
Profilerのhierarchy(階層)で検索します

ちなみにDeepProfileオフで測定してもヒットしません。
スペルミス に注意ですね(大文字・小文字の区別はないようです)
[KaomoLab]で検索するのもいいでしょう script関係がヒットします

(KaomoLab~~が たぶんscript関係でしょう 検証しきれていませんが)
ミリ秒順にソートされているらしく 処理時間の長いものが先頭にあります
今回は[EngineFacade.Update] をピンポイントで探せばよい
・・・という目処があるので心強いです
図のミリ秒を見ると   処理時間 51.88msとか 
 1フレーム63.92msに近い値です ぴったり一致はしてませんが
処理負荷の主な原因を表しているようです
今回の実験データではscript付きitemを20数個に複製し
script負荷を強調したものです 
No Details  を Related data にすると内訳が表示されます
(選択しておかないと何も見えません)20数個ならんでいます
なるほど [CodeRunner.Update]    は jsファイル1個分のようです
ひとつのscriptの処理時間が約2msであることも表示されています
この値が信用できるかどうか 後で検討します
自分の作ったscript名がそのままマーカー名とか
ブロック名として登場はしないようです 
慣れてくれば timelineよりは hierarchy(階層)の方が使い良いのでしょう
念のため、これを timelineで視覚的に確認してみます
hierarchy(階層)で選択してあれば 黒地に白文字の吹き出しが 表示されています
ショートカット[F]やホイールボタンや 
下段のエレベータを駆使して見え方をスケールします
図では[EngineFacade.Update]の長いブロックの下に
 [CodeRunner.Update]が20数個ぶらさがっている様子が見えます

これで、
「 EngineFacade.Update が1フレームのscriptの総計らしい
  CodeRunner.Update    がscript1個分であるらしい」
・・・ということを確認しました。めでたしめでたし


補足---------------
◯ 右肩の点3つメニューに show full scripting Method Names のoptionがあります
これだと先頭にKaomoとついているものがscriptがらみとして探しやすいです
慣れてくると短いほうが [CodeRunner.Update]を 探しやすいかもしれません

◯ Deep profile mode でフリーズの危険性
Script付きザリガニ50匹の重いシーンデータを測定できたのですが 
analyzeしようと load dataしたら フリーズしました 10分待っっても終了しません
Deep profile + analyze の組み合わせは危険です
文献によると
「ディーププロファイリングはリソースを大量に消費し、多くのメモリを使用します。
 ディーププロファイリングは、簡単なスクリプトで動く小さなゲームに適しています。
 複雑なスクリプトコードを使用している場合、
 アプリケーションでディーププロファイリングをまったく使用できない場合があります。」
・・・なるほどdefaultでオンになっていなかった理由があるのですね 一長一短があります

◯ Scriptの処理時間がそのまま信用できるかどうか
Deep profile モードでは profiler自体の負荷が影響して 
ほぼ同じ条件でも1フレームの測定値が異なりました
実験データでは 5倍も違いました
  DeepProfile オフ 1フレーム=12ms
   DeepProfile オン 1フレーム=63ms   
この状態で測定されたscript1つの処理時間をそのまま信用できるのでしょうか
何分の1か比率を掛けて補正すればよいのでしょうか 
Profilerは飽くまで 負荷原因を絞り込むツールであって・・・・
数値をよそに持ちだせるほど 本番に近い測定ツールでしょうか

◯ 手順Eが当てはまらない場合
scriptの本文が OnUPdateなら当てはまることが
scriptの本文が OnInteractなら その手順が当てはまらないようです
例えば 前前回の負荷測定用データ  test_ms_009B.unity  は Interact タイプなので
[EngineFacade.Update]や[CodeRunner.Update]が小さすぎて
1フレームの負荷を反映していませんでした
そこで [KaomoLab]で検索したところ
[InteractItemTrigger_TriggerEven] に着目したほうがよいみたいだと思われます
時間切れで 検証しきれていません。


・・・・・以上追記しておきます
飽くまで体験記です。
検証できていない 憶測も含みます 参考にする方は自己責任でお願いします

#cluster #ClusterScript