We’re seeing an odd performance issue with some of the blueprints in our game. These are sparsely placed blueprints that run some simple operation on (usually) a timeline component tick. The average performance impact of one of these actors is typically less than .1 milliseconds per frame, but sometimes they will spike and take 10x or more time to run on a particular frame. When looking in insights, the extra time shows up in odd places like basic engine functions or Kismet blueprint utility functions. Here are some screenshots of examples from a trace on a packaged build:
[Image Removed]
[Image Removed]
[Image Removed]
[Image Removed]
Is there an known explanation for why this could be happening, or is there a way for me to diagnose the problem further?
The thread is likely suspended. You can capture the ‘ContextSwitch’ channel which will show the activity on the cores and also at the thread level. You must run the game process as Administrator for Insights to be able to capture the context switches.
Thank you for your response. I captured the ContextSwitch channel on a Windows build and you were right. For the most part, those large unexplained gaps were just points where the game thread was suspended and waiting to be scheduled onto a core. I have a couple follow-up questions: I know that thread scheduling is handled at the OS level so it’s out of our hands to an extent, but is there anything I can do in the configuration to mitigate this? Something like giving the game thread a higher priority for the scheduler, although I would assume it’s already given a high priority.
I did test this on console as well though, and there I didn’t see this game thread suspension issue, since the game thread seems to have a dedicated core. However, I still saw some instances of functions taking much longer than they usually do with no details available. I’ll post some more screenshots here. They’re not as bad as the examples in the initial post, but it’s enough to be alarming:
It’s best to use other profilers to get to the bottom of it quickly. Superluminal would be useful here as it is a sampling profiler that displays the samples over time. You get a similar view than with Insights but it shows the callstacks that are sampled which provides a much higher coverage than Insights’ instrumentation.
Out of the 3 images, only BreakRotator looks suspicious. SetRelativeRotation can be expensive depending on the selected options (Sweep, Teleport) and the number of components to update.