One of our contractors reported huge stalls (0.5-3s) when playing our title in a windows build. None of the rest of the team appear to experience this.
He took an Insights profile and captured some of these stalls. They appear to be caused by the async loading on the game thread waiting a very long time for something to complete. Seemingly a texture to load in?
[Image Removed]
Looking further down the capture his I/O threads seem very busy around this time. I am not sure this is unexpected though since it is probably loading a streaming level. The loading also started many frames before the frame spike took place. This seems very similar if I compare to a insights capture on my PC, which has never seen this issue, so wouldn’t appear to be out of the ordinary.
[Image Removed]
No other threads appear to be doing any work during this time.
I have uploaded the insights capture. There are quite a lot of spikes (the majority this one). The one I have pictured here is at the very end of the capture so is probably the most interesting.
In case it makes any difference I am pretty sure the whole team is still on windows 10 where the contractor is on windows 11.
There is no known problems that are specific to Windows 11. The problem could still be related to the execution environment if there are some scanning software active (anti-malware\virus) or bad hardware. I would be interested to have a look at the log from a Development package if the problem also happens on those.
Is the title using IOStore or the old loader? If using the old loader, please make sure that you are using the “Event driven” loader option. It can be set from the project settings. You could also try activating IOStore (requires a new packages) to see if that resolves the problem. Lots of games have shipped with it using 4.27.
Which exact version of the engine are you using? Which stream did you procure the engine sources from and when?
I reviewed the trace and couldn’t find events that would be related to the end of the stall on the other threads. Insights rely on instrumentation so the trace is missing lots of contextual information. I would recommend profiling using SuperLuminal which samples the stack for all threads. That would provide a better view on the stall. Feel free to share a capture that we can review if you opt for this.
Another thing I would try is to run with a debugger and break the execution when the title stalls. The longest stall is 1+ second which should be enough time to hit the break button.