I’ve noticed from time to time that UE appears to freeze for a while but is really just doing something in foreground that maybe should be in background – and I can accept that. Tonight, though, I’ve run across – and figured out – an extreme case of this. I want to document what I learned, and also to propose that a lot of frustration for users could be averted by simply providing better UI indications.
I was working in a mid-sized project and needed to run an Editor Utility Widget (EUW) Blueprint, one which I’ve used previously (i.e., not new code). Right-clicking on the EUW to run it caused the editor to utterly freeze, not just for seconds, but for minutes. The hover tooltip remained frozen in place. There was every indication the editor was in an infinite loop.
Opening Task Manager, I saw that the RAM footprint of the editor was gradually increasing. No shader compilers were running, and Windows said the editor was “not responding.” Now, I know that doesn’t really mean much in Windows, because “not responding” just means the UI event handler isn’t responding, not necessarily that the program is looping.
Since I have Windows Subsystem for Linux (WSL 2) installed, I used “tail -f” to follow the project log in realtime, and found that no entries were being appended. Again, by all external indications Unreal was in an infinite loop, monopolizing one CPU core at 100% for a net load of 12% on my machine. After about 5 minutes, I task killed the editor, and restarted.
The problem was 100% reproducible. On the third hang, I decided to look online to see what solution might exist. I found references similar problems but nothing that closely matched my situation.
After about 10 minutes of searching, the editor suddenly became responsive again! The moment it happened was obvious because the fairly large asset info hover tip vanished.
Being a Linux geek by nature, the first thing I did was dive into the log again, to see what the first entry was after the freeze point. I think the answer is right there:
[2023.03.26-02.00.39:727][778]LogDerivedDataCache: C:/Users/*******/AppData/Local/UnrealEngine/Common/DerivedDataCache: Maintenance finished in +00:02:24.212 and deleted 0 files with total size 0 MiB. Scanned 80607 files in 64861 folders with total size 7934 MiB.
This message suggests to me the DDC was running some soft of routine cleanup or integrity check. That’s fine, but why did it do that in the foreground, an operation that took almost three minutes on an eight-core CPU 64 with GB RAM and NVMe SSD? If it was going to run that long, why not some sort of progress bar in the UI?
Furthermore, that “almost three minutes” isn’t the actual time. The fact is that there is a gap of over 11 minutes in the log just after this entry, which more accurately corresponds to the time I was searching for an answer before the problem resolved itself.
It may sound like a complaint, but I’d honestly like to know if there is something I may be doing wrong, or something I might want to look at in my engine settings, that causes this sort of problem? Is there a setting somewhere that causes single-threaded behavior by default, and I need to tell it I have a multi-core CPU it should exploit?
Any insights are welcome, and if this is not user error on my part, I’d appreciate suggestions on how best to frame a feature request to the Epic team – for example, should such a request focus narrowly on this situation or broadly on the question of thread management in the editor?
