Using the Unity Profiler, an Overview
Day 1 of optimization class and we’re going to learn about the profiler! To open it, just go to window/analysis/profiler. It was recommended to dock it below. I’ll use my first 2D shooter game as the subject to be optimized!
Running the game, we’ll see a realtime chart of how various elements of the game are performing. Here we can see things like CPU Usage which is focused on framerate, this is where we’ll spend 90% of our time. Seems here Physics is being quite a cpu-hog. Perhaps we’ll learn to control that later!
We can also scroll down and see performance in more detail like Rendering which is focused on drawcalls, batches, polycounts, etc. Memory management which is focused on how memory is used, garbage collection, etc. Scripts, physics, animation, garbage collecting, and much more.
We can scrub through a chunk of time in our game, though to understand what’s happening, you always want to change the timeline to Hierarchy in the profiler.
Here, we can see the editor takes up a whopping 80+% of our cpu cycles. Later, we’ll build the game and attach the profiler to see cpu performance in a real world scenario.
To use the profiler, we can hit the record button (the red dot) to begin recording a section of playtime. There’s also a Deep Profile button that can can track cpu spikes even deeper and give us the specific function call that’s causing those spikes. It’s recommended to always use it.
The editor is hogging up most of our cpu, there’s not much I can do about that, I want to concentrate on how my scripts are affecting the game so I turn off tracking of everything but the script.
As an example, I’ll play my space shooter, Playing the game, there seems to be a spike every time I fire the laser.
garbage collection went from a few bytes to almost 3k, which if spread over 60 frames a second is still not big of a deal relatively but could add up. Using deep dive, we can see that FireLaser is the culprit.
There’s a lot happening that could be optimized but right off the bat, there’s a Debug.Log() which is a memory killer! Debug.Logs() and Print() should be removed from a final product as they will bog down your app.
Playing the game now, there are still spikes but extremely tiny in comparison, I think this counts as a successful optimization!
This is just scratching the surface but one can already see how using the profiler will be a huge boon to optimizing games so they run fluidly.
