You can’t even begin to posit anything useful by looking at core load.
Particularly if you aren’t building the engine from source and using Visual Sudio’s debugging system to look at it.
It’s basically an exercise in wasting time this way…
That said, I doubt your cpu has any issue at all, but if there is ever any doubt, just run an occ benchmark instead of guessing at it.
Not saying everyone needs an A+ certification, but the stuff being mentioned is near rediculous. Dried thermal paste? Lol.
His CPU is an older XEON so it would be a possibility if the processor was thermal throttling. OFC insights would give a better readout of what is going on in engine during gameplay.
Worse culprit when it comes to frame rate is lumen + virtual shadow maps + volumetric clouds. Turn off those elements and you can get a lot closer to 4x’s performance at least on the default level.
There are some slowdowns like a worse world tick in any 5x version, but that is epics fault when it comes to optimization.
EPIC and optimization are oximorons.
Everone should know that…
And everyone should expect everything to work “less well” with any “new” release.
Particulalry if the release is in preview (which is essentially used to mean Alpha, if you can even call it that and not " we forgot we actually pubish the engine to the public, so here’s a build for you leeches who dont go and pull the source. Good luck getting things to work as we know full well they do not already").
Hence, my comment on it being Worse Practice to update engine versions on active projects.
That said:
Is the “tick time” really increased?
Probably not if you turn off stuff that’s on by default like Nanite, Lumen, etc.
The problem with the new engine is that Epic has a team working on it that is more green than grass, particulalry when it comes to graphics.
Or else, they would have never even suggested the whole Nanite thing would be viable or produce faster render times. It simply cannot, by design, at the moment. (GPU is faster than CPU, so bottlenecking your CPU to produce stuff that you then batch Twice in the GPU produces Extra load, not less, in no case ever will it have Less CPU load. Potentially, it can reduce GPU cost for bad scenes made bay lazy developers).
But they also do this constantly at the end user (and the gamer) expense.
Look at PhisX vs Chaos and the 80% performance drop that causes, for instance.
I do not know about you, but the list of Experimental and Beta plug-ins has grown in 5.5 I counted 5 media players for different OS’s, when I chose Windows as the platform I support. Besides, I do not make games, I sell assets, so do not need a load of media players, internet connections, analysing, google and a whole raft of others (mostly experimental) loaded into the editor by default, for no reason.
Obviously you need some of the plugins, turning off some means you lose access to the plug-in client, and requires a complete reinstall to get it back.
I don’t need Bridge, Quixel or FAB plugins running, none allow me to export directly to the store. They just sit there in case I might want to use them. It is tedious as I cannot find how to make the selection sticky between projects. I have to redo it everytime.
I am not a programmer, but I get worried when I see Unreal jump ship so quickly from Editor version to the next, after the previous version barely hits .2 or less. Constantly upgrading assets took up a lot of time and storage space.
I think the real problem is that the editor runs in the same thread as the game.
And all the editor processes consume too much CPU time.
So when you’re in the editor you don’t really have a thread to work on.
You can probably use half a thread or less.
Look, this is my performance in the editor.
And this is my standalone performance
As you can see the performance is 5 times higher in standalone.
The only difference between the two is that in the second case the editor is not present in the game thread.
So I think Epic should do everything they can to get the editor out of the game thread.
Or do everything possible to be able to use multithreading because right now the use of threads is very limited (in fact you can do almost nothing with threads).
It would be even better to have multiple “game threads”.
A single thread for the game is becoming insufficient nowadays.
Hello everyone, I have some news.
Part 1
I’ve been gradually disabling game functionality to isolate the source of a performance issue, and today, I’ve finally found it.
Somehow, the turret actors are causing the game’s performance to drop.
The interesting part is that this happens only when the turrets are spawned on a ship (the game is about space battles, and large ships have around 20 turrets).
If I place 20 turrets directly into the scene, everything works fine and performance is excellent. But if those same 20 turrets are spawned on a ship, performance takes a hit.
To investigate, I implemented a delayed turret spawn
Part 2
I also generated an Unreal Insights report. At the moment, I have no clue why the same actors would impact performance differently depending on how they’re used. If anyone could review the report and share a theory, I’d greatly appreciate it.
I even tried disabling all functionality in the turrets, but it didn’t help at all.
SPAWNWEAPON moment in the report
Try to close the details window.
In my case I found that this window is causing a 30FPS drop in a completely empty level.
With details:
No Details:
If you need that window again you can reopen it from here:
In fact you can close the window of the world too
And do not block the content browser
I actually gained a few FPS by closing all the windows.
Yea, well, no one should ever have told you to use the editor to do benchmarking - but just in case let’s make that clear:
You have to build as the final build, and test that final build for performance to know anything realistic about what a player will experience.
Does the ship move?
Is there replication in place on the objects?
Do the turrets use Tick? If so, look no further. disable tick on them. make them all work off a manager
(manager → collection of stuff → tick, loop collection of up to 20 items and perform tick task).
That’s called Tick Aggregation. rather basic practice.
Is that a screenshot taken in the editor?
Try doing it in Standalone… in the editor you will get worse results.
I took a look at your trace anyway.
It seems that metasound is one of the culprits (But not the only one).
I think you’re making 2000 calls to a dynamic material (or a Niagara system)
And the garbage collector is crazy too
Are you destroying a lot of objects?
Do the trace in Standalone… you will have more reliable results…
Then you will have to spend a good while reviewing it.
With this trace I would say that it is not a single thing but the sum of a few.
I agree, but we need the editor to run at acceptable FPS so we can design and do quick tests…
Just a minimum to be able to work.
Without that minimum the editor itself makes no sense.
And if the editor itself consumes all the resources of your only available thread…
At this rate, the next versions of Unreal Engine will be completely useless.
I’m actually seriously thinking about going back to UE4.27…
Thanks for the review
yes, the reason is simple, I don’t want to switch to 5.5 if the performance in the editor is going to be so bad.
yes I know it eats some CPU time
Oh, will check it. it clearly shouldn’t be like this
Probably, I will check it too. I know a couple of places to check
Thanks for your help, I will fix all issues and check it in editor and in the build to get more clear view
Both no
Yes of course. I tried to turn off the most CPU-consuming part by killing shooting component with a tick functionality but there was no difference at all
That’s really weird stuff!
There were actually many more things to check…
I only told you the first ones I found…
You will have to review the trace with more patience.
A pleasure to help you!!
It’s not unusual… it’s overlapping windows.
But I assumed EPIC had fixed this issue since it is a game editor… obviously they didn’t.
Yes, thank you, I’m just not very familiar with this tool and often don’t even know where to look. But I’ll learn sooner or later
You are supposed to close everything down when testing performance.
In 4.25/7 it was enough to just close extra windows you may have popped open…
Re the current issue.
If you have a moving niagara particle emitter on a moving object and - if your particles are set to track collision - you could be generating the CPU bottleneck rather easy just from Self Collisions.
My problem is with the pawn movement component (just 8 pawns causes a 30FPS drop in the editor)… I’m looking for ways to optimize that without breaking my entire game.
I have tried many optimizations that I have not been able to apply because it is a multiplayer game.
But I don’t give up!! 
However, this would not be necessary if the editor did not monopolize the entire game thread for itself.
As a benchmark / experiment that’d be pretty interesting actually. Strip back the world to a test project that can run in both versions. So if you’re in a position to do that, for sure definitely try it and report back the results.
In profiling / performance / optimization threads, devs like to talk about draw-calls and other things a lot. But often its just basic Actors MOVING through the world that can kill framerates. So placing turrets in the world is nothing. Its when those turrets are moving and are parented to ships that are also moving, that’s when the truth wins and reality kicks in. 
That’s why there are ECS and other plugins around. So a drop of 30 FPS seems pretty OK or typical actually. Overall, how many of these ships / turrets can be in the scene at any time? As anything moving in the world that’s say 100-200 spaceships / 100-200 AI (using-out-of-the-box settings) will typically start to hit start framerates or maybe even cripple them. 
Heavily optimizing / doing substitutions (including disabling collision) for ships that are further away or not as near, will reclaim some of that drop. But that’s a lot more work obviously. So anyway apart from ECS… There’s also a series of Assassins-Creed like crowd-optimization tricks that can help to inspire / improv solutions. Otherwise you’re fighting Unreal Engine most of time. That’s why Epic typically cheat in their own samples. Using things like basic emitters or other crude animation to simulate moving vehicles… But how about the Matrix demo? 
There’s got to be some interesting vehicle tricks going on there. 
