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.
But why sleep BEFORE we have work to do? wouldn’t it make sense to give us as much time to perform our frame as soon as possible and THEN sleep?
Even then, I can’t maintain 60fps if I managed to somehow put everything into a 0ms budget
Surely this wouldn’t be as much of an issue if we could do things independent of frames…
I wish they would just let people run stuff without linking onto runservice events. Even task.wait uses runservice heartbeat.
Still an issue, regardless.
It’s sleeping because it has not been assigned anything, there is nothing it can do because the frame hasn’t reached that point yet. I think it’s like when your FPS is capped, the engine just sleeps between frames not doing anything.
I think, usually, when your Thread label is very long, it means that that specific thread is ready to perform work, but can’t because another thread somewhere else on the Microprofiler is still doing some other prerequisite work.
Yes sleeping is common for RCC because FPS is capped. However it could be a Microprofiler reporting issue because it does look strange. We are investigating further…
If you’re sharing CPU’s with other roblox game servers can you work to group game servers by similarly performing frame-times so that game devs who actually work to optimise their code for the 60fps target don’t get punished by the weakest chain in the link, thank you.
Or even better, give us a solid frame-time budget (even if that’s 8.333ms, just give us something to work towards)
Just give us a solid target to work towards and then we can try. having it be seemingly random and not having any control over it makes all my optimisation efforts for nothing.
I’ve noticed that only some users get this issue. I’m 99% sure it’s something to do with the Micro Profiler gathering metrics during that Thread duration. I had a friend test it and the Thread job didn’t show up in his profiles. Performance definitely isn’t affected by this Thread job (outside of maybe while running a profile).
