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.
I know what would happen.
I would have to recreate all the blueprints and maps.
But all my bluprints are just data.
All code is in C++, so it is 99% compatible with UE4.27.
And all my assets I have made with Blender so the only inconvenience is creating the blueprints and maps again.
Even my behavior tree is made in C++.
I think I could do it if necessary.
The results will be better in UE4.27 (In the editor). Because the UE4.27 editor consumes less resources… But in Standalone it will be practically the same… I’m sure there is not much difference.
Are you talking about entity component system (ECS)?
I tried it in unity a few years ago… it was experimental.
I haven’t seen anything like that in Unreal yet.
I don’t think it will work for my AIs anyway, I have a very complex behavior tree.
I don’t know if you read my comment above.
I have excellent performance in Standalone.
My whole problem is inside the editor.
In any case, all the ideas you provide for optimization are appreciated.
I’ll take a look at all of them!!
Thank you so much!! 
