vsnry
February 18, 2018, 2:54pm
#1
Aren’t these both looping every 0.1 of a second? The RenderStepped loop decreases my fps a lot, while the other one doesn’t.
local frame = 0
game:GetService("RunService").RenderStepped:Connect(function()
frame = frame + 1
if frame == 6 then
frame = 0
for i = 1, 100 do
print(i)
end
end
end)
while wait(0.1) do
for i = 1, 100 do
print(i)
end
end
I checked with tick() and they both are looping at approximately 0.1 of a second, so why then does the RenderStepped loop decrease performance so much?
vsnry
February 18, 2018, 3:00pm
#3
They both fire approximately every 0.1 seconds.
1 Like
just realised how stupid my reply was, ignore me
1 Like
vsnry
February 18, 2018, 3:03pm
#5
Happens to the best of us
1 Like
XAXA
February 18, 2018, 3:04pm
#6
Related reading: RunService.Heartbeat switching to variable frequency
Since the only high-frequency signal in ROBLOX at this time is RenderStepped, some developers of games and scripts are using it as a signal to run the game logic, custom animations, custom replication etc. at. Due to the way ROBLOX frame is scheduled, this limits the performance of games in certain cases. In the worst case, running code in RenderStepped as opposed to Heartbeat can slow down the game by ~2x.
Also a good post by @buildthomas on the same thread: RunService.Heartbeat switching to variable frequency
If you look at the picture above, you can see that RenderStepped blocks the execution of any further steps until it yields. It runs before all the Rendering / Network Replicate / wait() resume / Humanoid / Stepped / Physics / Heartbeat. So if you stick all of your code in there, it means that all that code has to execute before the rest can begin. In that same image, everything after RenderStepped does run in parallel. So there are two pipelines there, and the top one (Rendering) will run in parallel with the bottom pipeline (all the other stuff). The bottom pipeline doesn’t block the rendering of the next frame.
2 Likes
