Avoiding wait() and why

Old post but isn’t using delay (as well as spawn) bad practice as well because they’re slow and/or unreliable or was I just misinformed?

Yes, but it was an example for the sake of showing how you can work without wait. In my own projects I had a custom delay, nowadays I’d just use task.delay.

I used to use repeat wait() until but I realized that it took far too long. Thank you for the alternative suggestions.

I’ve seen that guy not really like while wait() do (I don’t like it too) so my guess is that they did that so you can’t do that

1 Like

Okay but what about things like

Part.Touched:Connect(function(hit)
wait(5)
print("player touched part")
end

Is it fine to use wait() in this situation? If not, then why not? A lot of people still use wait() and I don’t see that changing to be honest.

1 Like

well I do
task.wait() replaces wait()
sooner or later delay(), wait(), and spawn() will get deprecated

Some people say that replacing wait with something like this

while THETIME > CURRENTTIME do
RunServiceEvent:Wait()
end

It actually isn’t.

task.wait(n) is better because it is done on the C side, and because it doesn’t have to resume and yield every runservice event.

I like the wait() command so no.

You’ll start to dislike it the more you use it in important loops of scripts or scripts that may break if you use it too much.

1 Like

Well i am still a beginner at scripting, so i guess…

Even though you’re just a beginner, a little optimization tip will not hurt you.

3 Likes

Time to click the replace button and type “wait” with “task.wait”

The opposite. My custom wait module is still more accurate than task.wait specifically because of it being implemented on the C side - it has to converse back and forth between the Lua and C APIs, which slows down execution times by an ever-so-slight amount.

In my years of using wait() it has never broke, so I’m not sure what you are talking about. It does exactly what it’s supposed to do.

The only difference between wait and task.wait is the fact that wait updates at lower rate making it less accurate.

I’m talking about optimization and accuracy.

He’s not mentioning your wait function as far as I have noticed, and the example he showed is slower, by a lot.

On yours, you handle everything in one thread, almost no allocation at all every frame, which is why it’s much faster, not having to switch from thread environments much at all.

His example code has allocation every frame for every current wait running, and that’s because a:Wait call has to create a signal listed list node, and that takes some time and memory.

I don’t really use wait because it is still a code smell mostly, but the only issue I have with your wait scheduler is the fact that I believe this line of code would resume the second wait right away, and just iteration problems which could all be fixed by using a linked list implementation.

RBXWait()
-- Thread is resumed, moving to next wait in list
RBXWait() 
-- This is the next wait, and it's resumed immediately because the time passed is higher than 0.

Reverse order of insertion here, like what happens with linked lists would fix this.

I had a situation something like that with you implementation, but I don’t remember exactly what code I used. But I do remember having an issue quite like this, and even if this little pattern is rarely used, it’s still a structural problem, one could be fixed by sacrificing speed just slightly.

It would not.

local RBXWait = require(game.ReplicatedStorage.RBXWait)

-- Wait for Roblox to load in
RBXWait(1)

print(RBXWait(), os.clock())
print(RBXWait(), os.clock())

-- Output:
0.017238000000361 161779.085962
0.015033899981063 161779.1011233

I was assuming he was talking about mine, as it is the most popular custom-wait module by miles.

Most of what I said still applies to task.wait(). The only part that doesn’t is the bit about slowing down the task scheduler. The rest of the article, referencing the anti-pattern of repeatedly wait()ing still applies.

2 Likes

I would suggest edditing the title to explicitly say that, as from what I (and presumably you) have seen, people still believe that it’s a accuracy thing, and not the fact it’s a code smell.

It would bring more people to this topic and actually go through understanding wait’s actual structural issues. I personally remember thinking I knew what this topic was about when I didn’t, and I didn’t go through with reading it.

“Avoiding wait (and task.wait) and why” would be nice.

1 Like

Sorry I’m still a bit new to scripting but what does async mean and what would be an example of “someAsyncThing” ?