top of page

Week 9: Profiling and Optimizing

Updated: Dec 19, 2020

There are two schools of thought when it comes down to profiling and optimizing games. One thinks it should be done early and often, as the game is being developed, the developer(s) should think of ways to optimize the code in order to make the game as performant as possible. The other thinks that optimizing should ONLY be done when needed. They believe that developer time is more important, and hence do not worry about optimizing until maybe the end of the project.

I stand with the former school of thought, profiling and optimizing should be done early and often. I believe that developing gameplay systems without profiling them could lead to a performance bottleneck further in development if several of these systems are used at once. Then it will require double the work to rewrite the system, IF its even possible to optimize them.

So, with that being said, I started learning about UE4's profiling tools, and figuring out how I can go about shrinking UE4's packaged size.

I have written some of my notes below after watching the following video:


Obj List - Show everything that is consuming memory (storage) in project. Useful to see stuff what you don't want packaged.

STAT Unit - Shows how long it takes for each thread to do its work. Frame is the TOTAL time, however this is not a sum of the other threads, since they run in parallel.

Stat StartFIle - Starts recording how long each thread takes to process.

Stat StopFile - Ends the recording. Creates a .ue4stats file to be loaded into the Session Frontend Profiler in UnrealFrontend.exe

Stat Game - Shows the different kinds of ticks and how long they take to update.

dumpticks - Shows ALL actors currently ticking.

Stat SceneRendering - Shows everything that is being used for a draw call

ProfileGPU - Bring up the GPU Visualizer, which tells you all the passes the GPU is doing and how long they take

Using the ProfileGPU command, it is possible to get a rough estimate of the cost of the material, before calling the GPU visualizer, run the following commands: r.rhicmdbypass 1

r.rhithread.enable 0

r.showmaterialdrawevents -1


Make sure to turn off "Frame Rate Smoothing" and "VSync" when profiling. Use the command "r.vsync 0" to turn off vsync.

A lot of these commands can be found in your viewport settings:

I still need to take a look at the Unreal Insights tool which is supposed to be the better/newer profiling tool from Epic.

Using what I learned from the video. I noticed the game is currently GPU bound when played in editor on the desktop. The best optimization I can make currently is to remove the sky material, since that is what is making the GPU go to work.

This also means that I need to come up with a debug menu for my game to be able to see all the profiling data in the target device (iOS, Android), instead of my desktop.

Also learned that a FAndroidDeviceDetectionRunnable thread is taking a huge chunk of time, maybe I should turn off the Android plugins and targets until I have an Android to test on.

Now comes the travesty that is optimizing the package size, which I have not figured out quite yet. First of all, cell phone carriers limit the download size of an app over cellular to 100mb. Therefore, the rule of thumb is to make your package be under 100mb. Easy right? You would think that making a fresh UE4 mobile project with NOTHING in it would result in a package size smaller that 100mb, right??? Wrong, it ends up being easily over 200mb. So what can we do?

First, turn off ALL the plug-ins. Really, go HAM and turn off everything you are not actively using. If you think you might maybe use it in the future but are not sure, turn it off. Then in the Project Settings, under "Packaging", turn on the following:

"Created compressed cooked packages"

"Exclude editor content when cooking"

COMING UP NEXT: Figuring out how to add the following without UE4's package builder failing.



bottom of page