Detect and Avoid Common Performance and Memory Issues in Unity WebGL Builds

♪♪ Hello everyone, my name is Oz and I'm a Game Dev Evangelist at Backtrace Sauce Labs. Today we're going to see some of the ways we can avoid common performance and memory issues arising in Unity webgl builds. The first point we'll be taking a look into is managing performance. And a major constraint running a webgl build in a browser with good performance is memory. So in terms of memory, what are the problems and what are the considerations that we got to take a look at? So as you know, the complexity of the content you can run is constrained by memory. And the memory is allocated by the browser and the amount of memory it has available varies on a number of factors, including the device you use, the operating system you use, which browser you use, and whether it runs on a 32-bit or a 62-bit browser, and a couple of other factors. So to understand how memory impacts performance, it is very important to first see how memory is allocated in a Unity webgl build. For this, we need to take a look into Unity Heap. So what is Unity Heap, or a Memory Heap, as Unity calls it? So basically, this is where all runtime objects are stored, and these could include native objects, Assets that are loaded, Scenes, Shaders, Animation Files, as well as other managed objects. So it is worth noting that this Heap is one contiguous block of allocated memory. Until a few years ago, you had to allocate the max size of the Heap in the build settings, but now Unity supports Heap expansion on demand, depending on the needs of the game, and it's expandable to up to two games. However, the same feature can actually often cause your game to crash, especially where the browser fails to allocate one contiguous block of memory. And this is exactly why it's very important to keep the Heap size as small as possible. Now, to understand how we can keep the Memory Heap size small, we have to first take a look into what Unity does to all of the Assets and Scene data in a project, and what happens when you build a webgl application in Unity. So when you build a webgl application, what happens is Unity generates a.data file. And this is basically all the Assets and Scenes in the application that is required at the time of launch, and all of that is packed into a.data file, including Unity Scenes, Textures, Models, UI Sprites, audio Assets, Shaders, and pretty much everything else that you need for the game to run. And basically, Unity webgl does not have access to a real file system. Therefore, it has to create a virtual memory file system, and the browser then unpacks the.data file into this particular virtual file system. And the browser, while the game is running, keeps the data uncompressed. Now, imagine if you have a complex Scene with all sorts of Assets, including 3d Models, Shaders, everything. You can see how possibly it can run into memory issues and slow down the game performance as well. So the question then that arises is, what can you do to reduce memory? Well, there are a few techniques that you can adopt to reduce memory use. And one way, the most common, is to use Asset Bundle. So you could put all of the most frequently, but bigger Assets into an Asset Bundle, and load it, unload it, on demand, whenever you want. And it's also worth noting that the Asset Bundles are directly downloaded into Unity's heap, and therefore, they avoid extra allocation done by a browser. If there are big bundles, one technique is to possibly cache the data. And this is basically one additional thing that helps you to avoid re-downloading each time you actually play the game. So the third one is something called an Addressable System, which is an alternative to Asset Bundles. And sometimes it's touted as a better version of Asset Bundles. However, it does have some of its own share of problems, including supporting webgl builds out of the box. But there are some workarounds that exist to make it work. The next important consideration with regards to webgl builds is the Garbage Collection, or GC in short. So typically, what GC does is it locates and collects unused memory, and then reallocates it into the Unity heap. On other platforms, when GC runs, all running threads are paused to give time for the GC to check the stack. But this is not possible on webgl due to limitations in javascript. So what Unity does here is it simply runs once after each frame, because the condition for the GC to run on webgl is that the stack has to be empty, and this happens only after each frame is rendered. Now, we'll look into some of the examples of code that increase GC and reduce performance, and how we can actually write a better code. So in the first example that I have here, you can see how manipulating a string is a major cause of performance issues, and sometimes can also cause an application to run out of memory. And the primary reason this happens is because any manipulation of string causes Unity to create a new string each time, and this can quickly add up. For instance, if the code were to be part of the Abyte loop. This example you can see here is where you have a countdown timer showing on a UI, and the countdown timer text is being updated continuously in the Abyte loop by appending the countdown prefix with the countdown value. And each time you do that, it's creating a new string, which can quickly really add up, and is not good for the memory. On the right, you can see how this code is being rewritten into a better code, where we separate the label and the values, therefore avoid the string manipulation altogether. Here's another example of string manipulation. If it's used in large for a loop. In a non-webgl build, this might run as fine as it could be, because the garbage collector will be involved, but not so much in a webgl build. Because in a webgl build, it doesn't get a chance to get involved until the end of the frame, and therefore this will likely run out of memory and crash. Here I do have some other examples where you can optimize Unity code to reduce memory allocation and reduce the need for frequent garbage collection. When using strings, for instance, if you need to manipulate or append string, use StringBuilder instead of Plus. If you're using Unity functions, where the function will return an array and you have to do some array manipulations or iterate through an array, you should cache it before you use it in a for loop. For comparisons, like comparing a name or a tag, not many of us know that these accessors actually return a new string each time, so it's better to use, for instance, to compare to a tag, use CompareTag function. And last but not the least, in case of coroutines, one common thing we tend to do as programmers is to use a line that returns new waitForSeconds or waitUntil or waitWhile. So instead, cache it and use that, especially if you're using it in a for loop. While we spoke about the ways memory can be managed in some situations and how we can reduce memory use, there are some unexpected situations that can cause applications to run out of memory or cause applications to even crash. So this is where tools that can help debugging these issues come into play. So one of those tools is Backtrace, which I use in applications and games I make for any platform, and of course, webgl is no exception. So when I integrate that, I can see errors in real time and dashboard and help me troubleshoot performance and out-of-memory issues. Things like what we see today, these can be actually used, and then that information can be collected to fix further problems before they get out of hand. That's pretty much the end of the session. If you have any questions about webgl or Unity, please feel free to get in touch with me. My contact details are on this slide. Thanks for tuning in. ♪♪♪