Profiler doesn't show where the CPU time is spent

[martinasenovdev]

hello, guys, I’m trying to profile my game on a connected Android device. For whatever reason, in the hierarchy it is shown where the CPU time is consumed by nodes but if a node says like 70% and I expand it, the nodes inside of it don’t sum to the given percentage altogether. Some info is missing, I tried to enable Deep profiling, it doesn’t allow me to (it stays grey), switch to other views, but no luck. I still can’t see where the CPU time is spent. Can you give me any hints, thanks!

[MSplitz-PsychoK]

The unreported CPU time is likely spent on internal engine logic, though sometimes I’m not sure myself.

GC (Garbage collection) is often a source of CPU slowdown, and I see you have 279 calls to GC.Alloc. Any Garbage you allocate now (on this frame) must be cleaned up automatically by the CPU at some point. Generally, you create garbage when you use the “new” keyword or create/destroy GameObjects.

One way to get more out of the profiler is use “UnityEngine.Profiling.Profiler.BeginSample(“sampleName”)” and “UnityEngine.Profiling.Profiler.EndSample()” to create a new category in that profiler hierarchy overview and see the impact of the code between the beginSample and endSample. You might be able to identify what chunks of code in your RoomStateHandler.Update() cause the most slowdown if you cut it into several samples.

One thing to consider when using the profiler is that a behavior taking 90% CPU isn’t bad if the CPU isn’t doing much else at the time. I find the “time ms” and “self ms” metrics to be much more useful than the percents under “total” and “self”.

[martinasenovdev]

This is one of the way
JavaScript
JavaScript calculations, specially ones that trigger widespread visual modifications, can stall application overall performance. do not permit badly-timed or long-running JavaScript intrude with person interactions.

gear
Make a Timeline recording and search for suspiciously lengthy evaluate Script activities. in case you discover any, you can enable the JS Profiler and re-do your recording to get greater precise records approximately exactly which JS functions had been known as and the way long every took.

in case you’re noticing quite a chunk of jank for your JavaScript, you could need to take your evaluation to the next degree and acquire a JavaScript CPU profile. CPU profiles display wherein execution time is spent inside your web page’s functions. discover ways to create CPU profiles in speed up JavaScript Execution.

problems
the subsequent table describes a few commonplace JavaScript problems and ability solutions:

problem example answer
highly-priced enter handlers affecting reaction or animation. contact, parallax scrolling. permit the browser deal with touch and scrolls, or bind the listener as overdue as viable (see luxurious enter Handlers in Paul Lewis’ runtime overall performance tick list).
Badly-timed JavaScript affecting reaction, animation, load. person scrolls proper after web page load, setTimeout / setInterval. Optimize JavaScript execution: use requestAnimationFrame, unfold DOM manipulation over frames, use web workers.
lengthy-running JavaScript affecting response. The DOMContentLoaded occasion stalls because it’s swamped with JS work. pass natural computational work to net people. if you need DOM get admission to, use requestAnimationFrame (see also Optimize JavaScript Execution).
garbage-y scripts affecting reaction or animation. rubbish series can show up anywhere. Write much less garbage-y scripts (see garbage series in Animation in Paul Lewis’ runtime overall performance tick list).
style
fashion changes are high-priced, specifically if those changes have an effect on multiple element within the DOM. Any time you practice styles to an detail, the browser has to figure out the effect on all related elements, recalculate the layout, and repaint.

Thank you but I’m not using JavaScript. Everything is MonoBehaviour thus executing within the Unity Engine.

@MSplitz-PsychoK thank you for your insight, I’ll give it a try. However notice how time ms reflects the percentage shown. Still the subnodes’ total ms doesn’t sum up to the root node’s time ms

[MartinTilo]

Most Unity internal functionality should be wrapped in profiler samplers. If there is some functionality that takes up some time and does not have a sample, you’d see an “Unaccounted Time between X and Y” sample (at least in Timeline view).
However, what you’re looking at is the Update() method sample of your RoomStateHandler. When the engine is calling that Method, it puts a sample around it. When that method (or any method called from within) calls into Unity API, that will usually get a sample as well, which is what you’re seeing. Therefore, most of the time you’re missing would be your own code, that is not wrapped in samplers. Deep profiling will inject samplers for every Managed (Mono/C#) Method. You can manually do the same with the API @MSplitz-PsychoK mentioned, or the newer:

Unity - Scripting API: CustomSampler

Regarding Deep Profiling on Android. You’ll need a Mono build, IL2CPP is sadly not supported for Deep Profiling. (We can’t inject the samplers into AOT’d code on the fly, only JIT code). Next, Deep Profiling comes with an overhead so it is not running this way by default. You can enable it through adb though.

adb shell am start -n com.YourCompany.YourGame/com.unity3d.player.UnityPlayerActivity -e 'unity' '-deepprofiling'

You’ll need at least 2017.3 and currently, due to a bug in mono, the Scripting Runtime Version .Net 4.x Equivalent.

Regarding Allocations: Every new on a class type will allocate. Structs live on the stack and do not allocate themselves, unless something is causing boxing (such as making them nullable or passing them into a method that takes them as object). And yes, making an allocation takes time and so does garbage collection. You could turn on the graph for GarbageCollection and see, if that caused anything. However, since your Update loops already took a combined 92% I kinda doubt that there is additional time spend on GC but I can’t tell definitively from the screenshot. (btw, you can also save the profiling data and attach it here, if you want to)

I’m guessing your RoomStateHandler is kind of a level load? It looks like it is instantiating, activating and deactivating a bunch of objects. Maybe you should think about pooling common Prefabs or using Scenes for this which you can load and unload additively and asynchronous?