As a Roblox developer it is currently too difficult to identify and solve memory leaks with the tools Roblox is giving us.
Tracking down memory leaks is currently one of the toughest things to do for a developer due to the lack of tools and documentation. However, memory leaks can be detrimental to the success of a game and unfortunately it is very easy sometimes to cause these issues. Roblox is not doing a good job helping developers solve these issues and this has to improve!
Why the current tools are not good enough
Right now Roblox offers us a couple tools to help us identify ‘what is going on’. Unfortunatelty only one of those tools can be used to study memory management, which is the developer console. This console has a memory tab where you can see what kind of memory is being taken up on the client and the server. However, most of the tabs in the developer console are either not applicable, or they are confusing and non-descriptive. Take a look at the following sections for example:
Even though this screenshot was taken in a live server, it shows a studio/undo section which is not applicable in this case. More importantly however, many of these tabs do not mean anything to the average developer! What is a ‘video/texture’? What is a ‘render/target’? What is a ‘render/envmap’? What is a ‘default’? And additionally, are these megabyte values good or bad? The average developer does not know if having 38.4 megabytes allocated for the network/replicator is a good thing. Without context these numbers are meaningless.
Given how confusing this memory tab can be, you would expect there to be great documentation. But when I try to look up more information on the developer console on the developer hub, I am not given any useful information either. This page does list for some of these names what they entail, but the information is too broad and lacking to be of use. The information does not assist you in tracking down memory leaks!
On a brighter note, one thing about this developer console that is useful in identifying memory leaks is the history graph. When you click on one of the names, it shows a graph describing how the values are changing overtime. This is what one of those graphs might look like:
This could be useful to identify at what point during a game you notice memory going up. However, here you are yet again running into issues. As you can see, this graph only displays information from the past 30 seconds! Some games have introductions longer than that. On top of that, memory leaks are often tricky to deal with because memory is built up over time. Usually you will not notice that your game has a memory leak until hours into it. If at a given time I can only look back on the past 30 seconds how memory has creeped up, I am not left with any meaningful information. It does not help either that the scale is automatically adjusted. The jumps in the graph above look very big, but if you look at the values to the left, almost no memory is actually being allocated or freed.
Finally, from what I have noticed many of the memory leaks that are caused by developers end up in this ‘UntrackedMemory’ row. This could for example be when you do not clean up a table in a script and so it is kept in memory forever. So most of these developer issues are grouped into one number and there is no way to trace back where this memory is originated.
What tools we need
Given the issues I have described above, I personally think that the following features are must-have to help track down memory leaks, in order from most important to least important:
- We need to be able to track per piece of logic/code how much memory is being allocated and freed. This might for example be per script, or perhaps per function or block of code manually specified by the developer. Being able to isolate pieces of logic so you can hunt down a memory leak by process of elimination would improve the developer experience a ton.
- We need to be able to graph over a longer period of time how the different types of memory increase and descrease. Ideally you would be able to set the timeframe yourself and add tags that describe specific events in the game (such as: starting a round, playing a cutscene, parenting a map, and so on), so you can cross-reference memory changes.
- We need better documentation around how memory is classified, what each class means and what probable causes are when memory spikes in certain areas. It does not help when the documentation tells me ‘Write memory-efficient scripts’ when I notice that the LuaHeap is taking up a ton of memory. It is the equivalent of telling someone to ‘get good’ at a game when they keep losing.