I am migrating my project from UE 4.27 to UE 5.3.2 and I am encountering a severe performance drop. Normally I use the Unreal Frontend Profiler to determine what is causing the performance problem but it seems it has been removed.
I have tried using Unreal Insights for profiling this issue but I find this tool much more cumbersome and it doesn’t point me in the direction of the blueprints taking up all my performance.
What was wrong with the profiler inside Unreal Frontend? and why was it removed for UE5?
Is there any way to still access this profiler?
Frontend is still in 5.3 to my knowledge. Are you looking under the ‘Window’ dropdown? If so, it was moved from there in an earlier version to Tools>Session Frontend. I hope this helps!
My question is in regards to the profiler tab inside Unreal FrontEnd.
I have included 2 screenshots;
one of the UE4 FrontEnd, which has the profiler tab selected,
and one of the UE5 Frontend, which doesn’t seem to have this profiler tab.
Is there any way to access this profiler tab in the UE5 FrontEnd that I am missing?
I have tried using Unreal Insights but I find the data that this tool gives me much harder to analyze. I struggle finding the blueprints that are causing the performance issues using Unreal insights.
So it seems that UE 5.2 still has profiler and can open files created in 5.3. That is a work around for now. Insights is great but way too much info and not as direct as profiler.
I recently encountered an issue in Unreal Engine 5.4 where the Profiler tab seemed to be missing. However, I discovered that profiling still works—you just need to take a slightly different approach.
You can start profiling your project by using the commands stat startfile and stat stopfile. This will generate a profiling file, which you can find in the Saved/Profiling folder of your project.
Once you’ve got the file, you can load it in an older version of Unreal Engine that still has the Profiler tab available. This way, you’ll be able to view all the profiling data just as you did before.
I found some information about the missing profiler panel in this file Build.h last line:
// Controls whether old Profiler (UnrealFrontend/SessionFrontend/Profiler) is enabled or not.
// Old Profiler is deprecated since UE 5.0. Use Trace/UnrealInsights instead.
#ifndef UE_DEPRECATED_PROFILER_ENABLED
#define UE_DEPRECATED_PROFILER_ENABLED 0
#endif
The Frontend Profiler is deprecated in UE5. All work and new features with regards to profiling are now on Unreal Insights, which we recommend people use instead.
What is your workflow like which makes Unreal Insights less ideal to use? It’s supposed to be more powerful and show better what is slowing down your game than the old profiler. It would be good to know if we’re missing something.
@Ari_Epic Unreal Insights does, in general, do a better job regard of showing what slows the game down from a general sense; however, with regards to the game thread, that is all the further detail Unreal Insights provides - the usage of the game thread. As far as I have managed to use Insights or find information on the subject, no further drilling down of the game thread is possible.
In the Session Fronted profiler, one could drill down into the game tab, into blueprints, into events, and down into what specific nodes were taking up CPU cycles. None of this is true as far as I can tell in Unreal Insights. For CPU constrained games, such as a large RTS game with light graphics, Unreal Insights provides no assistance.
To make the profiler usable in this regard, users need to be able to determine what blueprints, events, and nodes within the game thread are taking up CPU cycles.
First, the Game Thread in the Timing Panel allows you to see graphically everything that’s happening in the thread. But you want to drill down into a list of what is taking the most time, right? A good way of doing that would be to select a single function which you want to see what is happening underneath it. In this example, I’ll click the FrameTime function:
The Callees Panel will then show you a tree view of every single function that it calls and how long it takes in milliseconds, sorted by the time it took, and even how many times it was called:
Sorry for the delayed reply; life happened. I re-ran a fresh trace with stat named events turned on and was able to drill down into more detail and find that information. This may have been the issue. I’ll have to play with it some more to be sure, but this should work in place of session fronted, despite the additional information being so vast.