The microprofiler on the server shows a label called “Thread” with no active labels underneath taking a long and inconsistent amount of frametime ranging anywhere from 5ms to 23ms every frame. There is no context of it’s purpose and no hints regarding on why it’s suddenly a large performance hit.
This has only appeared recently without changes meanwhile previously we’ve been able to stably keep well under the 16ms frametime budget.
A private message is associated with this bug report
Generally when that “Thread” marker shows up like that it means there is a thread that’s ready to do something but there’s nothing to do. However I am interested in the image that you posted because I can’t tell why one Thread took 17ms. Could you please post a dump HTML?
log_10B29_microprofile_20240930-084026.html (1.2 MB)
I’ve only noticed thread time being super long when its running on ROBLOX servers. Not sure if its because of the different in hardware though.
Thanks for the dump. I can confirm that the “Thread” marker represents time when we’re not doing any work. The inconsistent frame times are being investigated because ideally they would stay very close to 16.667ms
Hi, the dumps were attached in the private message.
Just to add to this, I’m noticing it in my game which very rarely has any extra frame time (I’m a really bad programmer) and I’m even seeing this in a blank baseplate taking upwards of 30ms sometimes.
log_97CC7_microprofile_20241104-112529.html (745.4 KB)
I count the time between frames on my game and these threads typically take minimum of 3ms, and I’ve seen upwards of 140ms (although I honestly think that’s a bug)
Here’s an example from my game:
I scale the amount of time I have for the PostSimulation step based on how much time I suspect I have in the frame to maintain ~60FPS. Whatever is happening here could really cause some runaway performance issues.
It seems really odd that this step happens before the game loop runs, since it doesn’t seem possible for it to predict how much time the actual step is going to take. Am I crazy? Unless the profile is incorrect, it doesn’t play this Thread job until the very beginning of the frame, which seems impossible as a “gap fill.” Here’s two separate frames showing what I’m talking about:
What’s happening in the attached image and MP dump is that the server has very little work to do and is sleeping most of the time. The “Thread” markers correspond in these cases to sleeping because we don’t go faster than 60 frames per second.
