Memory Analyzer

A successful Roblox game should run smoothly across all supported platforms including mobile devices and tablets. One key to performance is proper management of memory usage. Memory is particularly important on mobile devices. If a game uses up too much memory on a phone, it will cause the game to crash.

Terrain, parts, graphical effects, scripts, physics simulations, sounds, and more can all contribute to total memory usage. The Studio Performance widget displays metrics on a place’s memory usage which can be used to identify places that use too much memory.

Analysis Tools[edit]

There are two tools that can be used to observe the memory usage of a game. The first is the Developer Console which can be opened in both Studio and Client. The second is the Studio Performance Widget.

Developer Console[edit]

The developer console displays the current memory usage of the running place in the Memory tab:

MemoryAnalyzerDevConsole.png

The console can be opened on Mac and PC (both Client and Studio) by pressing F9.

Platform How to open Dev Console
Mac and PC (both Studio and Client) Press F9
Mobile (tablet and phone) Enter the message "/console" into the chat
Console Select Developer Console from the in-game settings menu

Performance Widget[edit]

The Studio Performance widget has a section that displays the memory usage of place. This widget can be opened by navigating to the View tab and clicking on the Performance button.

MemoryAnalyzerPerformanceButton.png

MemoryAnalyzerPerformanceWidget.png

Memory Types[edit]

Total Memory[edit]

When the Roblox client is running a place it takes some amount of system memory. This is referred to in Roblox as “Total Memory”. This value shows the sum of memory used by both internal Roblox processes (Core Memory) and place specific elements (Place Memory). This number is measurable through the Performance widget, but is also viewable through OS tools such as the Task Manager on PCs or the Activity Manager on Macs.

Core Memory[edit]

There is some amount of memory that will always be used by the basic infrastructure of the Roblox client. No matter how small or simple a Place is, some memory will be used for some processes built into the engine that are common to all Roblox games (such as networking, avatars, user interface elements, etc). All of this memory is called “Core Memory”.

Place Memory[edit]

Place Memory is essentially everything but the Core Memory. Place Memory is effectively:

(Place Memory) = (Total Memory) - (Core Memory)

Place Memory is the memory that scales as a direct result of choices made as a Place is built. The Studio Performance widget breaks down this memory into “Developer Tags” which can be used to identify how each type of element of a game is affecting the game’s memory footprint.

Developer Tags[edit]

All Place Memory is assigned a Developer Tag to help associate that memory with a particular design choice. Following is a table of all Developer Tags, along with suggestions on how to optimize memory associated with each tag.

Name Description Suggested Steps
GraphicsMeshParts Graphics for Mesh parts. Use fewer or simpler Mesh parts.
GraphicsParticles Graphics for particle systems. Use fewer particle systems or produce fewer particles with shorter lifespans.
GraphicsParts Graphics for parts. Use fewer or simpler parts.
GraphicsSolidModels Graphics data to render Solid Model objects. Use fewer or simpler Solid Models.
GraphicsSpatialHash General rendering. Use fewer parts, particles, lights -- anything that contributes to rendering.
GraphicsTerrain Graphics for terrain. Use less terrain.
GraphicsTexture Texture memory. Use fewer or smaller textures.
GraphicsTextureCharacter Texture memory for characters. Use fewer unique character appearances.
HttpCache Assets (images, meshes, etc.) loaded from Roblox servers and now held in a cache in memory. Load fewer or smaller assets.
Instances Instances in the Place. Use fewer instances. Everything in the data model (all of the objects in the Explorer widget) is an instance (e.g. parts, scripts, lights, etc).
LuaHeap Heap memory for both Core scripts (scripts that ship with Roblox client) and custom scripts. Write memory-efficient scripts.
PhysicsCollision Collision data for physics simulations. If a part doesn’t need to move set Anchored = true. If a part never needs to collide with anything (including Avatar), set CanCollide = false.
PhysicsParts Physics geometry and kinetics. Use simpler, smaller, or fewer parts.
Script Lua Scripts. Use fewer or shorter scripts.
Signals Signals that fire between Instances: an event fires on one Instance to trigger an event on some other Instance. Use fewer event connections between instances.
Sounds In-memory sounds. Use fewer or smaller sounds.
StreamingSounds Streaming sounds. Use fewer streaming sounds.
TerrainVoxels Terrain voxels. Use less terrain.
TerrainPhysics Terrain physics. Use CanCollide = false , and/or Anchored = true for objects close to terrain.

Studio Inaccuracies[edit]

When working with memory analysis tools, it is important to note that Studio will use more memory per place than Client. This is because:

  • Studio supports undo/redo so it may have multiple versions of certain objects in memory.
  • Studio keeps separate data models for "edit" and "player" purposes as this makes it easier to clean up after running a simulation of a game.

Since Studio's increased memory is mainly a matter of scale (objects being counted multiple times), while the numbers in Studio aren't reliable in absolute terms, it can still be useful to consider then in relative terms. For example, if the "Sounds" developer tag has a much larger value than other tags, it is fairly safe to assume that Sounds should be optimized first. If changes result in a lowering of the value of the tags, then those changes should also be reflected in Client.

Again, this caveat only applies to Studio - any place memory measurements in Client will be accurate.