Simple Way For Tracking UObject Memory Use#
- obj refs name= S_Hex_Urban_Standard_03 shortest
- memreport / memreport -full
–LLM to enable low level memory tracker
Low Level Memory Tracker (LLM)#
Detailed explanation: https://qiita.com/donbutsu17/items/a72a282587390f43d12d
The Malloc Profiler is a tool built into the engine that can be used to write out memory profiles, which can then be later read by the MemoryProfiler2 C# tool to help find memory leaks and other memory issues. Here are the steps explaining how to use it.
The malloc profiler is currently best supported on Windows, but Linux, iOS and Mac should work. Newer console platforms and android are currently not supported. In general you want to run the profiler on a Cooked Windows build of your game if possible.
- Rebuild your game with the malloc profiler enabled. The easiest way to do this is to add “true” inside the section of your BuildConfiguration.xml file. This will set the USE_MALLOC_PROFILER define and disable frame pointers. Once you do this you will need to rebuild your game
- Open the MemoryProfiler2 tool, you may need to compile it first. To compile load Engine/Source/Programs/MemoryProfiler2/MemoryProfiler2.sln and build that project. There may also be prebuilt binaries in Engine/Programs/MemoryProfiler2/Binaries
- Launch your game that has been compiled with the profiler on, this will start writing the memory profile to GameName/Saved/Profiling. It will be in a timestamped folder and named GameName.mprof. Your game will probably run much slower when in memory profile mode.
- While the game is running you can run “mprof mark MarkName” in the console and it will write a mark named MarkName to the profile, which can then be used later in the tool
- When done with the gameplay you want to profile, run “mprof stop” in the console and it will flush the memory profile and write it to disk, which may take several seconds. You can then close your game. I would suggest not profiling more than 5 minutes or so of gameplay, long sessions may cause the profiler to run out of memory.
- From MemoryProfiler2 open your saved mprof file by selecting File->Open and navigating to where it was saved. This may take a long time.
- You will now be on the Callgraph view, with nothing visible. You now need to set the parameters in the toolbar and then hit the Go button to get useful information. The defaults should be fine for now. The Callgraph view gives you a top down overview of memory allocations, and you may be able to find something interesting by expanding the categories. Here is what it should look like after hitting Go:
- The exclusive view is probably the most useful view for finding memory leaks. By default it will show you all allocations that have happened since the beginning of the project, which is very useful for finding large allocations. You will need to hit Go on this tab as well to make it generate useful results. Here is what it will look like with the default settings, and selecting the top allocation:
- To find leaks specifically, you want to change the Diff Start and Diff End points to something more useful. You can select from the Marks you added at runtime, or several autogenerated marks on events such as map transition or garbage collection. In this example I want to see the memory that’s been allocated while in a certain level so I selected the start as the LoadMap End of the first level, and the end as the LoadMap Start of the second level. Then I hit Go again to refresh the results:
- The other tabs are useful for tracking different types of memory problems. For instance the Timeline view can show you an overview of memory allocations over time, to look for issues at a glance:
- On the timeline view you can also create Custom Mark Points by clicking on a specific point on the timeline. If you then reopen the profile a second time those mark points will be available in the start/end drop downs. This can be useful for investigating specific increases in memory
- Also, the filter options can be useful to help investigate issues. You should experiment by filtering certain classes or text strings in/out and then hitting the Go button to refresh the view.
For most memory issues, internally we use all of the following to try to track them down:
obj list - console command which will list all of the object classes and the corresponding counts and memory usage, obj list class= shows all of the objects for a particular class
MemoryProfiler2 - tracks every allocation the engine and game makes and writes a report, can be used to track leaks as well, shows a visual graph of allocated memory, this can take some time to write out the report at the end as it is symbolicating all of the callstacks for the memory allocations (looking in to doing this allocation on the mac instead after the fact).
Instruments Allocation template - also shows all allocations, but includes system as well, has leak detection
Your best bet for finding fragmentation is either 2 or 3 as they can give you a more complete picture of the current state of memory.