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” ?
Something that doesn’t happen instantly. For example, Player.CharacterAdded.
1 Like
So from what I understand task.wait() doesn’t necessarily allow you to do polling since event based waiting is still faster, but it can replace a custom Wait() function since both are effectively running on a heartbeat/renderstepped timer but the only difference is that a custom Wait() is slightly more accurate?
From what I read creating a custom Wait() timer is there to prevent throttling, and if task.wait() also prevents throttling then it should be completely fine to use as a replacement as long as you don’t really care for extreme precision?
1 Like
I’m looking for memory leaks in my code(looking for scripts suspiciously increasing in memory cosumption), and I came across something:
wait() does not increase memory usage(according to the server memory in the console log), while RunService.Heartbeat:wait() does. I find the memory usage resets sometimes, but sometimes it keeps going up, consuming several megabytes.
BindableEvent.Event:wait() does not have this memory “leak”
Is there a reason for this?
Did you try the task.wait? Latest one?
I tested that one alongside the other wait alternatives, it did not build up memory over time. I’m converting to that wait method when I need something run periodically(but not per-frame)
You should always use task.wait where you would before used wait, since task.wait is basically a replacement for wait that is both faster and better.
1 Like
I would just like to say, wouldn’t you need wait for like a gun system where you can fire only ever 0.25 seconds (debounce) or reloading takes x long?
This post goes over the abuse of using wait and its derivatives for unnecessary polling (i.e., repeat task.wait() until value), not for the actual practical use of yielding code for a set amount of time
In short, if you’re using task.wait(n) to yield code appropriately you’re not doing anything wrong unless n is a really really small number, and if that’s the case then just bind your function to a RunService event!
2 Likes