Using the Unity Profiler
Now that we’ve gone through a few different projects, let’s take a look at how we can go about using Unity’s profiler. This tool allows us to get performance information about the applications we have created. In order to get it going, we have to open the window for it:
From here, we can drag the window to an area that is comfortable to work from and take a look at what some of the modules that we can view our data on:
We are also able to customize which modules we want to look at:
When we try to view our information, a breakdown shows up at the bottom of our window. This as it initially looks isn’t the easiest to read so we will want to change it from a timeline to hierarchy:
While we have the game open in the editor, the editor itself will take up a lot of the process. For now, we will work around with it within the editor and later on take a look at how we can go about playing the game and utilizing the profiler outside of the editor.
A feature that is nice to have turned on is the deep profile:
This feature let’s us dive deep into the frame spikes and let us know the specific function call as to what caused the spike to occur. When we go to play our game, we can see it begin to collect data. This will not save all the data that is made in the game session, but just for about 200 frames or so worth of data:
When testing, we can play the game while paying attention to any spikes and pause the game to see what is the cause of those spikes, as well we want to look at some of the other categories within the spike. There are a few different columns of data that we can take a look at in the hierarchy:
The total and self are what % of the allocation is to the specific category. As for the GC Alloc, that is the total garage collection allocated to the specific frame. When we see something around 5kb or so, it’s not too much of a worry, as it isn’t a huge amount when multiplied into a full second. However, once the numbers start creeping into 30kb, we need to start looking into it a bit more as over a second, that is roughly 1.8mb worth of garbage data that has to be dealt with:
As we can see here, after playing for a bit we can see how it spikes up to about 10.2kb, when it is generally sitting around 4.7 when idle. As for the breakdown of why it is so high, we can see that it the debug.logs that we have running for the game are taking up a bit of garbage space. Now, if we had 10 different debug logs running, and they all were around 4.8, almost 5, that would result in a lot of garbage piling up in the application every second.
When releasing a game, any debug.logs and prints that we have still active within our game take up a huge amount of information. To prevent all of this garbage from piling up within the game, we simply want to make sure that any of the debug.logs that we have set up to check on certain events when creating our script to be sure it works proper is just simply comment out or remove that log completely.
Now that we know about Unity’s profiler, we can further investigate into our applications to try and find issues to fix to create a smoother experience for the user.