Using the Unity Profiler

Objective: Utilize the Unity Profiler to Observe Game Performance

As this is part of the last section, I felt it only right to test out the Unity Profiler on the first project of the program. To get the Profiler set up with the Project, go to Window, Analysis and Profiler (Shown Below).

As you can see, the Profiler window launched mid-screen. To get the clearest ability to view the performance while the game is running. Dock the Profiler under the Game View.

On initial run of the Game with the Profiler in default settings, you will see something similar to the image above. This can be a bit intimidating at first.

If you expand the view and scroll, you will there are a lot of options for tracking performance. We can track CPU usage, Rendering, Memory Allocation and so much more. To go through all of these setting would take a mini series itself so for the purpose of the post, we can minimize to more of a basic and quick overview but if you want to delve deeper, you can find the full documentation here and there is a very nice blog on tips for performance profiling and more here.

For now, we can just focus on script profiling by turning off all the other options.

We will also change from a Timeline view to a Hierachy look to focus on some specific topics.

Finally we will turn the Clear on Play and Deep Profile options on.

Looks a little less intimidating. In the top panel of the Profiler, we can see real-time tracking of the frame rate and spot any anomalies by spikes that will appear. These spikes represent frops in frame rates, stutters and glitches. While the game is playing if you left-click on the area with a spike we can see data appear in the bottom panel.

Notice the spike near the left. While the game is paused after clicking on the profiler, we can select that spike to take a closer look. Take note of the values in the bottom panel of the top image and then compare them to the ones in the image below while the spike is selected.

Unfortunately, because I’m on a high powered PC and the game itself doesn’t require that much resourses my frame rate is a little too high. That and at the end of each project I clean up all Debug Prints and even Comments from my scripts make it a little harder to show issues(I have placed a few Debugs back in and we may have to add a few more Debugs to show you what I mean).

If we look inside the bottom panel we have two main focus targets. The PlayerLoop and the EditorLoop. the Editor itself takes up some process and can cause some issues itself. Our focus here though is the PlayerLoop as that’s we’re we can do the performance optimizations. If you move right, we have some tabs.

The spike we are looking at is caused mostly because of two things. A Coroutine and a Debug after the Asteroid gets destroyed and the first wave is called.

For now, I will remove the Debug and we can come back to to the Coroutine in the next post.

The main focus here is to reduce the Garbage Collection(GC) as much as possible. By removing a SINGLE Debug, we have successfully reduced the GC from 8.7KB in a single frame to 438B (roughly 95% reduction).

Imagine multiple Debugs in a single Method or Call! We don’t have to as I’ve placed three in place of the one I removed.

I think the image above speaks for itself. You may be thinking but its only 18.5KB. That’s a single frame. At 60 frames, that could be 1.1MB and that’s a single method. Games generally will have multiple methods being called at once and the more complex the game the more the calls. They will add up. This was just an example of one area of the Profiler. In the next post, we will look a bit more and work on optimizing Coroutines.