yeah… thats why its flawed. All scripts requiring the customWait function at the same time will use that single bindable meaning that that the customWait will terminate much earlier than expected. If you have 20 scripts in your game imagine how many times bindable:Fire() is going to be called.
thats cuz of the flaw lol. Without the flaw you would have to be doing Instance.new(‘BindableEvent’). Creating objects aren’t instantaneous and so is the creation of a connection.
Ik she’s famous. But whatever she said had 0 proof. There is no mentioning of the “primary queue” or “secondary queue” on task scheduler docs? Spawn should be used only in moderation to prevent those delays she’s getting. Spawn uses wait() which comes from 30HZ pipeline. That is correct, but threads in general are expensive in the first place and should not be spammed.
Spamming 100 - 1,000,000 spawn in a “benchmark” would not even be practical in an actual game development standpoint.
Like I said, there is no mentioning on task scheduler docs on this “primary or secondary” queue. wait(5) inserts 1 instruction into the scheduler which is absolutely harmless. It’s not recommended to constantly call wait() or runService.Heartbeat:Wait() into the scheduler in the first place which would technically be polling.
I advocate the use of runServiceHeartbeat:Wait() over wait(–no arguments) when it comes to yielding for a frame. I never stated that wait(-- no arguments) should be used over runServiceHeartbeat:Wait().
oops got off-topic again lmao.