Your UE 5.4 sounds corrupted or you have some kind of overlay / benchmark software that is wrecking the performance. Any type of FPS or software overlay will affect its performance. I found that out the hard way when I discovered Riva Tuner running in the background messing with it.
was this reported using the bug report tool? same is happening for me on 5.3.2.
Actually game thread and RHIT are parallel in editor for 5.3 and then it fails to do that in packaged project.
How can we get a dev to look at this, itâs a huge performance problem but clear that it works totally fine in-editor as far back as 5.3 so like whatâs the issue here
@skfabby sorry to ping you, just wondering if there is a way to pass the replied threading issue on to relevant team as this is a serious engine issue affecting performance across many platforms
Same issue for me on RTX4080 and RTX3080
Iâve passed your message on. 
1 Like
Thanks so much 
I had reported the same issue here also before realizing others were having the same problems:
And for me, even as far back as 5.3.2 RHIT runs parallel to Game Thread in-editor:
But in the packaged game (both shipping and development) they run sequentially, meaning that packaged projects run about 30% slower than projects in-editor simply because RHIT wonât run in parallel:
You can see the frame time is about 4ms worse in packaged projects because of this issue.
Parallelization was listed on the roadmap for the 5.4 Release, so Iâm not sure why it works in-editor in the older engine version 5.3.2 and then not at all in packaged projects or in the later 5.4 and 5.5 releases even though this was a major selling point of those updates.
Itâs also worse on some hardware than others. I have an RTX 4080 PC that suffers badly from this. On the RTX 3080 with Outdated NVIDIA Drivers installed, it doesnât happen at all.
In theory, the 4080 should be a much faster card but the older 3080 system outperforms it significantly (90FPS on the 3080 system vs. 55 on the 4080) because of time spent waiting for RHIT to run in sequence (the above screenshots are from the 4080 system). Both PCs have Intel 12900 CPUs running on the same version of Windows 10.
1 Like
I didnât report the issue. I once put a bit of work into reporting a bug, but it wasnât even listed in the tracker. Not sure what happened there, but Iâm not going through that process again.
I think posting an obvious UEInsight screenshot on this forum in a thread about UEâs performance should be sufficient to get the issue heard.
Usually this kind of stuff gets solved/fixed at some point and I/we have learned to be patient with UE. Despite the (many) hick-ups, UEâs still the best engine out there (by far!).
I think posting an obvious UEInsight screenshot on this forum in a thread about UEâs performance should be sufficient to get the issue heard.
I wish I had your optimism, some of these issues have been in the engine since 5.0EA which was about 3 years ago and still not addressed :'D
Just to note, @skfabby same issue does indeed appear on 5.4.4 with the RHI Interrupt and RHI Submission Threads.
Reduction in FPS from ~90 down to 37.5. Entirely attributable to these threads operating asynchronously
It happens spontaneously but as an added trigger I have found calling Load Level from Blueprint can sometimes trigger the issue. The only fix is to completely close and restart the application.
You can see here 18.9ms of Game Thread doing nothing but waiting for RHI:
For context 18.9 ms is longer than an entire frame should take.
2 Likes
Hey, just adding to this.
Recently went live with a public playtest and getting massive RHI stalls for maybe 5% of players. Initially thought it was AMD cards (as they were in the majority) but also happening on NVIDIA cards.
No idea whatâs causing it.
Hi, yes I agree the engine has got work over time and Epic don`t seem to be just ignoring the fact hoping it will go away! I have been using the Unreal engine for coming upto 3 years now. I noticed an issue when we moved from UE4 to UE5 in general. Inconsistent frame rates, poor performance. Unfortunately the engine has gone downhill since then and the new technologies like Lumen and Nanite still need ALOT of optimization.
I disabled virtual textures and the hitching I posted earlier seems to have gone.
Unsure as to why, will keep investigating.
Just a thought: virtual assets are streamed into the engine; usually from disk. If you are streaming from a platter-drive it can be problematic, or even a slow SSD.
Best served with an M2-level drive as the I/O speeds are an order of magnitude(s) faster.
Also, if you do not have enough RAM to store the assets, memory management will start thrashing as it has to reorder the cache, free space for new stuff, etc and spend more on overhead vs processing.
For 2025 readers.
A reminder to backup, backup, triple backup and (not a backup) version control (Git) if you take your projects seriously. Upgrading, corruption other forms of data loss is no joke.
Even UE4 was full of bugs and didnât get the love of much required fixes. The only way to get those fixes was to move to UE5 which was a marketing move. UE5 then blew up with more experiments instead of moving to a LTS structure, which is very disappointing. Too often, 1 fix came with 5 bugs.
This cr"p causes burnout:
Also hard to work with when you are doing an X year taking project and wish to stick with a version, instead of kicking the entire framework away from underneath it halfway.
1 Like
Just started running into similar issues with 5.4 - the project was originally in 5.1 but in a fairly empty scene performance went from 6-7ms to +12ms on an RTX 4090.
The scene didnât use Nanite or Lumen so I tried switching between DX11 and DX12 as well as SM5 and 6.
I recalled that UE5.4 introduced LWC for materials, so I also tried converting some material math but it had no noticeable effectâŚ
What DID end up helping was changing some of the quality settings!
Basically TSR at Epic would eat up around 1ms but the rest were for some reason due to the Post-Process quality setting - setting it to Low would restore performance to UE5.1 levels.
I know that 5.1 used to have an issue with correctly setting the screen percentage, but I always force it at %100 regardless of other settings so it is not a factor in these tests.
At the moment with Post-Process being at Low, it looks like some effects just donât render at all - in my case the only noticeable difference was the Vignette effect (but I guess I can manually add that back). The project also had some post-process materials but they were unaffected by the Low setting.
From the look of things there are likely changes to some default values for certain Post-Processing effects that at least for me had a massive effect on performance and setting it to Low basically disabled them.
Ambient Occlusion