I’ve been looking for the best way to profile an Unreal project (both CPU and GPU), but it seems there isn’t a suitable built‑in configuration:
Development includes debug/assert overhead (check(), ensure(), etc.), skewing timing results
Test removes asserts but does not enable STAT groups, NamedEvents or ProfileGPU
I know Unreal Insights works in Test by default, but it doesn’t provide the immediate feedback you get from the “stat” command when, for example, changing a CVar value. Also, from what I’ve seen, enabling USE_STATS incurs more overhead than I’d hope, since all counters run every frame regardless of whether the stat command is active. Though for GPU profiling I assume the performance difference isn’t that big.
Since there’s no official “Profiling” configuration:
Are we expected to change the Test configuration when needed with macros like ALLOW_PROFILEGPU_IN_TEST or FORCE_USE_STATS? That doesn’t seem ideal, as that oftens means that the entire engine needs to recompile.
Is it advisable to create a custom “Profiling” configuration derived from Test (since there are so many #ifdefs with UE_BUILD_TEST in the codebase) but with the necessary macros enabled?
If so, why isn’t such a configuration provided out of the box?
Both Development and Test are used for profiling in different situations at Epic . For CPU, Development is generally be used as a starting place since the extra instrumentation (STAT & Trace) can be useful to identify slower BPs\objects and is “cheap” enough to identify the bottlenecks of the title. We usually recommend to start with the default channels when using Insights and only activate other channels or the named events when looking for the extra information as this can be fairly intrusive. Test is faster since a lots of the development systems\tools are turned off. We use it with the Replay system and the CSV profiler to get average times when validating code optimization or CVars combinations. We mostly care to know if the replays are better\worse on average to validate the impact of potential optimization. We do look at “instant” improvement with the Stat systems but the view is very narrow and lead to bad choices.
For GPU, the new GPU profiler now sits under ProfileGPU by default. It will be the same metrics from the console command or Insights.
We recommend using sampling profilers (CPU) or the specialized GPU profilers when looking for even more details. The CPU sampling profiler frequency can be tuned to favor details (higher) or “truer” performance (lower) depending on the moment. Those can be used with any target (Dev, Test, Shipping)
We have lots of licensees that are targeting for the Test target to run at their desired FPS so that the extra optimization of Shipping ensure that there is room for unforeseen event (hitches) so that the FPS is as smooth as possible.
Regarding your 3 questions, the current configurations are the ones Epic is using to ship its own games and demos. We do not claim them to be perfect so we do added the possibility or customizing them using the Macros. You should not try to add new targets as they are used in the UAT and UBT code (UnrealTargetConfiguration). Adding a new target would require extending those tools and sub processes which would be expensive in the end.
You can inject the macros through multiple way:
TargetRules.GlobalDefinitions: You can add to this list from your Target.cs file. You will need to use a unique build environment or override the build environment:
This compiles project specific version for the Engine modules and increases the size of the Project’s Intermediate folder.
The default is to share the Engine module compilation artefacts that live under Engine\Intermediate and the Engine plugin’s Intermediate folder.
Override: TargetRules.bOverrideBuildEnvironment
Force different build settings on the UE5 shared artefacts
Please note this creates discrepancy when compiling the UE5 project which can trigger a full recompilation of the engine. It’s best to apply this one through the Engine’s BuildConfiguration (see next point)
BuildConfiguration.xml: You can have a stack of build configuration to modulate how the engine is compiled on a specific PC. Each location has a specific scope and they apply in the order they are listed in the documentation.
Some features can also be activated through launch arguments to UnrealBuildTools.
The properties that can be modified through arguments have the follwoing defore their definition in the CS code: [CommandLine(“-XXX”, Value = “YYY”)]
When using UAT\AutomationTool, argument for UBT can be injected using -ubtargs=“-Arg1 -arg2...”
Using those methods allow to create special builds that can be used for specific situation such profiling.