Why are loops with decreased intervals + wait times slower than increased intervals + wait times?
So I noticed this a few weeks ago, but haven't really been curious until recently.
I noticed that whenever you're running a loop with an increased interval and increased wait time, it's actually faster than one with a decreased interval and decreased wait time.
Now if you're confused by what I mean, here's an example:
wait(5)
local pastTime = tick()
for i=0, 1, 0.01 do
wait(0.01)
end
local currentTime = tick()
print ("The 0.01 process took "..(currentTime - pastTime).." seconds.")
pastTime = tick()
for i=0, 1, 0.1 do
wait(0.1)
end
currentTime = tick()
print ("The 0.1 process took "..(currentTime - pastTime).." seconds.")
Now I ran this and found out that the 0.01 process took 3 seconds, whereas the 0.1 took 1 second.
Why is this? I know that scripts take time to run code and it's not instantaneous, but I'm sure it's more than just that.
0
0
2 answers
Wait
The most significant issue here is how wait functions internally. The minimum time that the scheduler can wait until it resumes it's next task is close to 0.03 seconds in a smooth game environment. This interval can increase depending on other script activities or coroutines, and in fact, can reach a significant amount of delay when overhead is high enough. This is another reason why using wait for things like animating can be unfavorable.
For Loops and Binary
Another issue is how for loops behave, or more specifically, how binary behaves. Decimals cannot be accurately represented in binary, and thus, can yield strange results when compiling. What you get instead is an over-approximation to your decimal value, which can throw off the for loop by several iterations. Have you ever noticed that the following code...
for i = 0, 1, 0.01 do
print(i)
end
... stops at i = 0.99 instead of i = 1? This is due to that very reason. Instead what you should do in situations like this, is use whole numbers for your start, end, step values then divide them later on. Example:
for i = 0, 100, 1 do
print(i/100)
end
This way you're still getting an approximation, but it's not interfering with the binary logic of the for loop on a lower-level. This contributed less to your results than the wait problem did, but it still contributed something, and it's good information to have in general for other potential instances like this one.
1
Those numbers make sense. Take the smallest wait time, ~.03333333 seconds or so, and multiply it by 100, the number of times your first loop goes. You get something pretty close to what you've found. Then, do .1*10, again, pretty close to what you got.
I think what you might be confused about here is in thinking you can wait(.01), but you just can't wait() such a small amount of time.
I believe that if you go into the roblox studio settings, somewhere under the Lua tab you'll find the minimum possible time to wait