This page is superseded by the Performance, Profiling, & Optimization home page. Please see that page for current information on profiling and optimization in Unreal engine 3.
Performance and Memory
Making a game that both runs well and fits withing memory constraints is an exciting problem that touches upon many systems and many disciplines. This page is your gateway into a large number of tools and techniques in which to help you win the battle. Even with the best tools in the world, you still need to instill the mindset of making certain that people are using the minimal amount of data / cpu cycles to create what they want. The tools and techniques listed here will help you do exactly that.
To do that we break the large problem into a number of sub problems to allow us to focus on each area in as much of an orthogonal way as possible. This allows multiple people to work/scale independently.
Each section has an overview and then all of the tools/techniques that are applicable to that section. for each tool/technique we give a brief reason why you want to utilize that tool / technique. This page is meant to give you a quick overview and point you to a more comprehensive too/technique page that will have all of the details on how to utilize that specific tool/technique.
Keeping Your Game Working
Keeping your game running is a balancing act between constantly adding new content and features VERSUS fitting within your budgets. When adding new content, often it will be added with incorrect settings or will be more expensive compared to existing content. Usually these mistakes are just innocent oversight. But with the amount of content games are utilizing these days it is hard to track.
The following tools/techniques will help you maintain a working game:
Find out about build breaks due to bad checkins as soon as possible.
Finds "questionable" content that should be looked at and probably fixed.
Catches rarely executed code crashes / issues.
Makes certain that the game is always playable and people are not just looking at features in an isolated test level.
Allows for easy catching of performance / memory regressions.
Makes certain that there are no redirectors causing content to be loaded when it should not be.
Automated system which will gathers performance and memory stats on specified levels.
Makes certain that textures are in the correct LOD group and fixes incorrect texture settings.
For all of the optimizations you need to do for your game here the following techniques are universally good to apply when working.
This page Performance Debugging also has information about tracking down performance problems, bottlenecks and hitches.
Instead of spending hours optimizing something, sometimes it is better to just turn it off!
Look at a wall and see what is still spending costly cpu cycles when it is not being rendered.
Having N of the same type of object really shows what parts are slow without getting drowned by the rest of the engine's functions.
Here are a few STAT commands that are useful for quickly check hitchy things at run-time - typically line checks and path finding. Look at the Max values to spot hitchy frames.
- STAT UNITMAX - Use instead of STAT UNIT, in order to catch hitches better.
- STAT COLLISION - Look at "Multi Line Check" and "Single Line Check".
- STAT NAVMESH - Look at "Generate Path".
- STAT SLOW - Shows all stats that are slower than 10 ms. It seems that you have to type STAT NONE to turn it off.
One of the areas we need to be constantly looking at keeping under control is the amount of Memory the game utilizes. Getting a view into what is using memory is the key to this process. The following will help you do that.
Also, visit the Memory Debugging page to learn about tracking down memory leaks, bloat and fragmentation issues.
Determining what you are always paying the cost for even if it is not being used. You want to minimize this amount.
Looks at a set of maps and shows what content they reference in addition to showing global usage of content for those maps. Allows you to focus your optimization efforts on the biggest bang for the cost.
Looks at all content and allows you to see the relative costs between assets.
Instructions on how to create "Hot Spot Reports" for your level designers. These reports can be created by your QA department and are useful in identifying memory dips due to sub-levels streaming in and out. They will allow your LDs to better see which buckets are costing the most memory, and should allow them to optimize their levels to better fit in memory.
Determining what your DVD footprint is and distribution of data on it.
You can often bloat your executable by accident. Knowing what is in your Executable is a good thing.
Will look at all of the content and find textures that have been duplicated over time. This will then fix up references to point to just one version of the texture.
It is often really nice to view asset allocation as a histogram / list of categories with an amount next to them.
Not all meshes need to have per poly collision and turning it off will save memory.
Overview of some techniques that Level Designers can utilize to make certain their levels are not doing anything slow.
A command that will list out all of the major memory utilizers. It allows for fast and easy overview for where memory is going and is diffable.
Tool to see exactly where memory is being allocated. Useful for tracking down non UObject leaks.
There are a number of pools in the engine that will grow over time.
Making certain that your TArrays are not wasting space.
The Texture Pool is a fixed size, but what occurs inside that pool depends on the settings that Textures have.
Animations that are unused take up precious memory. This will show you how to find them and remove them.
Every object that is added to the scene takes up some resource. Usually the most interesting objects take up the most. In order to have lots of GameThread CPU time for those objects we need to make certain that other objects are not unfairly utilizing resources and that we do the minimal amount of work needed to accomplish our goal. There are a large number of specialized tools/#defines to help you do that effectively.
To get set up for profiling check out: PerformanceDebugging
Determining what and AI is doing that might be expensive.
How to identify slow areas in animation.
The log is your friend. Messages that show up in the log should not just be ignored but instead the root cause should be found and fixed.
Dynamic Light Environment have a number of settings to make them both performant and look nice. Getting the correct settings for the type of asset is vital.
Understanding what is being GarbageCollected and reducing that churn.
Ways to avoid executing and linking in code that never actually used in your shipping game.
Minimizing the number of line checks done per frame.
Determining why levels are taking a long time to stream in.
Utilizing the all powerful #define LOOKING_FOR_PERF_ISSUES 1
There are a number of pools that help with spawning performance. Making certain you are using them.
Determining what actions are causing the NavMesh to be slow.
When there are lots of moving actors determining which ones are slow is important.
Finding which Particle systems are the most costly.
Every frame things are occurring. Some are more expensive than others. Determining what those are is vital.
Physics is run asynch but can still be expensive.
Techniques to use when profiling the GameThread.
Techniques to find out which parts of your Skeletal Meshes are slow.
UnrealScript optimizing can be one of the fastest gains. Finding the slowest functions and either converting them to c++ or optimizing what they are doing.
Constantly spawning objects is slow and we want to avoid that.
Many actors only need to be "active" based on an event and do not need to be ticked every frame.
There are a large number of useful exec commands in the engine. We detail a number of them.
When you have splitscreen, the renderthread has to do most things twice. So in many cases your only option is to reduce the fidelity or disable.
Techniques to use when profiling the Render.Thread
When you have an under performing GPU or are having to rendering too many things sometimes just disabling is the best bet.
Determining which objects are casting dynamic shadows or very large shadows.
Making certain that shaders are doing what you think they are doing and not wasting GPU cycles for no visual gain.
Each platform has a number of specific GPU tools to help you profile effectively.
The console command allows to lock the view to a given view to allow better profiling.
Shows exactly what is being sent to clients.