I have this problem just in Project Browser, I use mangohud to show whats happened with fps, I call it fps burst
Yes, whatever is causing this bug should really be patched. I am curious though, this issue should be affecting many more users, which seems to be the case as there are other threads popping up regarding similar lags. I hope it catches the attention of the developers
Just upgrade to UE5.4 yesterday and encounter editor lag
- Disable UDP message plugin
- Disable TCP message plugin
- Disable Telemetry plugin
as the previous posts suggested seems to remedy the issue for me. Will continue testing.
Confirming that disabling plugins:
- UDP message plugin
- TCP message plugin
- Telemetry plugin
Lag/freeze every 1 second completely disappears in my system.
But I still believe that this issue must be addressed by UE developers ASAP, because even with this “some” kind of fix, the engine in its current state is under ‘Unreliable’ status.
2 Likes
I just updated to 5.4.1, and everything was smooth when I opened the project. However, after about 5 minutes, when I switched to another application and then back to UE, the issue occurred again. I checked the logs and found three identical lines of warning, all saying “LogD3D12RHI: Display: Temp texture streaming buffer not large enough, needed 8388608 bytes”. So, I tried to find where to adjust this buffer. However, I’m not familiar with the editor settings, so it took me some time and I still couldn’t find where to make the changes. But magically, after searching for a while, the severe lagging issue was suddenly resolved. However, when I switched back to the Chrome browser and then back to UE again, the severe lagging issue reappeared. I’m not sure if this is related to UE’s power-saving mode while running in the background.
Experiencing this too - stuttering in the editor making it completely unusable at times. Narrowed it down to the studio telemetry plugin with a slow running blocking timer every 0.5.
LogEngine: TimerManager's time threshold of 100.00ms exceeded with a deltaT of 816.8984, dumping current timer data.
TimerData 000004EF519BA160 : bLoop=true, bRequiresDelegate=true, Status=3, Rate=0.500000, ExpireTime=5702.008334, Delegate=DELEGATE,NO OBJ,vtbl: 000004EF87185DD0 func: 0x7ffdfe85ba60 FStudioTelemetryEditor::HeartbeatCallback() [D:\build\++UE5\Sync\Engine\Plugins\Experimental\StudioTelemetry\Source\StudioTelemetry\Private\StudioTelemetryEditor.cpp:401]
LogEngine: TimerManager's time threshold of 100.00ms exceeded with a deltaT of 697.5638, dumping current timer data.
TimerData 000004EF519BA160 : bLoop=true, bRequiresDelegate=true, Status=3, Rate=0.500000, ExpireTime=5703.008334, Delegate=DELEGATE,NO OBJ,vtbl: 000004EF87185DD0 func: 0x7ffdfe85ba60 FStudioTelemetryEditor::HeartbeatCallback() [D:\build\++UE5\Sync\Engine\Plugins\Experimental\StudioTelemetry\Source\StudioTelemetry\Private\StudioTelemetryEditor.cpp:401]
LogEngine: TimerManager's time threshold of 100.00ms exceeded with a deltaT of 623.2133, dumping current timer data.
TimerData 000004EF519BA160 : bLoop=true, bRequiresDelegate=true, Status=3, Rate=0.500000, ExpireTime=5704.008334, Delegate=DELEGATE,NO OBJ,vtbl: 000004EF87185DD0 func: 0x7ffdfe85ba60 FStudioTelemetryEditor::HeartbeatCallback() [D:\build\++UE5\Sync\Engine\Plugins\Experimental\StudioTelemetry\Source\StudioTelemetry\Private\StudioTelemetryEditor.cpp:401]
Unfortunately I can’t disable this plugin as it’s depended on by the “asset search” plugin which is in turn depended on by the “flow” plugin which my project is using. For those who are unable to disable the studio telemetry plugin, you can stop it from stuttering by adding the following lines to your project’s DefaultEngine.ini:
Windows:
; Studio Telemetry Settings
[StudioTelemetry.Log]
FileName="nul"
Linux:
; Studio Telemetry Settings
[StudioTelemetry.Log]
FolderPath="/dev/null"
This effectively cancels out the expensive synchronous file writes that it’s doing.
5 Likes
Disabled the three plugins yesterday morning and used UE all day - zero issues.
I think this is the best solution so far.
(post deleted by author)
By deleting the given “sky light” and re-doing the lighting setup in the “env light mixer”, my FPS went back up to 120. This is how I fixed the issue.
Thank you very much. This method indeed resolved the current issue for now. Everything is back to normal after I disabled Studio Telemetry plugin. However, I still hope the official team can fix this issue, as Studio Telemetry is a default-enabled built-in plugin, and some functionalities rely on this plugin to work properly.
1 Like
Thank you so much. The issue is resolved for now with these three plugins disabled.
Typing this command in the console seems to make the lag go away for me: r.RHISetGPUCaptureOptions 1
Adding this line works on my end, the program is stable and smooth as the previous version.
However, all the tests I’ve been doing for the past 2 days are with some default basic UE5.4.1 templates and a few small heightmaps, I still haven’t migrated my project over 5.4.1 to see how it handles way more heavy and complex things.
I just hope when I do so I’ll not encounter issues and it will be as smooth as 5.3.2
1 Like
I have this issue in 5.4.1 in PIE and noticed it does not happen in standalone. Disabling these plugins did nothing for me. I did some actual profiling with Insights and saw excessively high Slate Tick Time with QueryCursor showing 85.3ms. I had also noticed that having another window open makes the fps drop go away, so I tested some more with it. Every time I moved the cursor over the viewport the fps plummeted. Bringing the cursor back to hovering the project settings window (or any other open window) made the lag spike go away. Tested this repeatedly with 100% consistency. Something they did seems to be making the cursor poll excessively while in the viewport in PIE. I wonder how long we’ll have to wait for a fix for this. Hopefully Epic is already aware of this issue and working on it.
Thanks,
NeoExcidious
I have the exact same issue.
For some reason this console command also made the lag go away for me: r.RHISetGPUCaptureOptions 1
Haven’t been able to do any more testing since due to escalating problems with vs (going to be spending the rest of the day removing and reinstalling.)
Found this (https://dev.epicgames.com/community/learning/knowledge-base/ze7b/unreal-engine-renderdoc-ue4-how-to-get-shader-symbols):
- It is recommended to enable r.RHISetGPUCaptureOptions=1 via command line before taking a capture as this does the following:
- Enables high level markers during the frame like ‘BasePass’ and ‘PostProcessing’ (covered by EmitDrawEvents above)
- Shows a marker around each draw call with the material uses (including material names etc)
- Disables the RHI thread. Some events are lost when parallel rendering is enabled
My guess is that the lag is caused by the parallell rendering that apparently is disabled when using this console command.
Edit: “r.rhithread.enable 0” also removes the lag.
(About the command: “If Set to 0, will disable the RHI Thread completely. Command lists will still be generated, but they will be translated directly on the Render Thread at certain points.”)
I am glad that it helped. I suppose for now, it’s either disabling the plugins or implementing the RHI fix as suggested later on. Thank you for helping out on resolving the lag issues by testing out potential fixes on this topic! Have a good one 
Edit : Okay this is an even better solution, sorry for missing out on that
Bump. This is a massive problem and makes the editor completely un-useable. I cant even revert my project back to 5.2, what a mess.
2 Likes
Thanks for reporting. We’ll have a look.
2 Likes