こんにちは、Unityエンジニアのオオバです。

日曜日の夜って、日常の業務から開放されてUnityリファレンスをぼ〜っと眺めることがあると思うんですが、本記事はそういう時に起こる発見をメモするシリーズです。

ところで、CPU負荷をUnity上でサンプリングする時はProfiler.BeginSample()を使用していました。

Unity2017からCustomSamplerというクラスが追加されていて、そちらを使った方がプロファイル自体の負荷がProfiler.Beginより低いとのことを最近知りました。

Using CustomSampler is more efficient than using Profiler.BeginSample to profile your code. This is because CustomSamplers that have been created in advance have very low Begin call overhead compared to Profiler.BeginSample.

👉DOTweenの教科書を読んでUnityアニメーションをプログラミングしてみよう!

使用方法

Profiler.Begin()とほぼ使い方は変わりませんが、予めCustomSamplerインスタンスを作っておかなければいけません。

CustomSamplerTest.cs · GitHub

という感じです。

繰り返しになりますが、オーバーヘッドがProfiler.Beginより小さいらしいですが、それだけでCustomSamplerに置き換わることは無いと思います。

CustomSamplerの本領発揮は、Recorderと組み合わせた時でした。

CustomSamplerからRecorderを取得

var recorder = _customSampler.GetRecorder();  

// CustomSamplerでプロファイルした処理のナノ秒数をログ出力  
Debug.Log(recorder.elapsedNanoseconds);  

このようにCustomSamplerからRecorderインスタンスを取得することで、CustomSamplerで計測した処理の秒数をスクリプトで取得することができるため、ログとして吐かせたりいろいろ出来るようになります。

Unity Profilerで見るしかなかった部分をスクリプトから取得できるようになったという点が大きいと感じています。

また、とある処理が指定秒数を超えたらhogehogeするみたいなこともやろうと思えばできます。

Unity Profiler内の処理もスクリプトから取得できる

Unity Profilerによる計測時間をスクリプトから取得できた件_0

例えばCamera.Renderの処理時間をスクリプトから取得すということもできます。

ReorderTest.cs · GitHub

CustomSamplerではなく、Recorderが神という事ですかね。

参考

オススメ記事
検証環境