Scripting HelpersARCHIVE
A little piece of Roblox history. Preserved for everyone, one question at a time.Read about the archive →
All questions/Question #59468
✓ ANSWER ACCEPTED

Why are loops with decreased intervals + wait times slower than increased intervals + wait times?

Asked 333 views2 answers

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.

AnonymousEdited

2 comments

0

Strange. Are you sure you are looking at the decimal part? Mine gets 3 seconds/1 second.

Anonymous#
0

The 0.01 process took 3.351261138916 milliseconds. The 0.1 process took 1.2149202823639 milliseconds. I might be wrong and it could be seconds.

Anonymous#

2 answers

✓ Accepted answer

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.

AnonymousEdited Permalink

1 comment

1

I would like to add on a proof that there is an underlying issue, by doing some math and getting rid of how long it took for the wait()s to run you can conclude that the difference in run times was high, for me 2 seconds, if there were no underlying issues it would be close to 0.

Anonymous#

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

AnonymousEdited Permalink

This discussion is preserved as it was. New answers, comments, and votes are closed.