こんにちは、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インスタンスを作っておかなければいけません。
という感じです。
繰り返しになりますが、オーバーヘッドがProfiler.Beginより小さいらしいですが、それだけでCustomSamplerに置き換わることは無いと思います。
CustomSamplerの本領発揮は、Recorder
と組み合わせた時でした。
CustomSamplerからRecorderを取得
var recorder = _customSampler.GetRecorder();
// CustomSamplerでプロファイルした処理のナノ秒数をログ出力
Debug.Log(recorder.elapsedNanoseconds);
このようにCustomSamplerからRecorderインスタンスを取得することで、CustomSamplerで計測した処理の秒数をスクリプトで取得することができるため、ログとして吐かせたりいろいろ出来るようになります。
Unity Profilerで見るしかなかった部分をスクリプトから取得できるようになったという点が大きいと感じています。
また、とある処理が指定秒数を超えたらhogehogeするみたいなこともやろうと思えばできます。
Unity Profiler内の処理もスクリプトから取得できる
例えばCamera.Renderの処理時間をスクリプトから取得すということもできます。
CustomSamplerではなく、Recorderが神という事ですかね。
参考
この記事が気に入ったらフォローしよう
- Unity 2018.2.12.f1