To everyone proving spawn() is bad. That is a false claim. Instead of trying to find solutions to how to make spawn bad by spamming 100 - 1,000,000 spawns, it is better to use more practical proof. Threads are not meant to be spammed in the first place even if it’s just a “benchmark” just like @MisterHumbled stated. In general, threads are expensive.
spawn() is delayed since it uses wait() but it only yields for 0.03 seconds. The timing of how much spawn can yield depends on how much you spam spawn because of internal work in the task scheduler due to the fact that yielding tasks are managed in the scheduler.
Referenced from Task Scheduler docs:
" The task scheduler coordinates tasks done each frame as the game runs, even when the game is paused. These tasks include detecting player input, animating characters, updating the physics simulation, and resuming scripts in a wait() state."
A custom spawn uses bindables which neglects the cons of coroutines and the delay of spawn which is good. But I’d rather not create a bindable + connection each time I want to create a thread even in moderation.
Spawn() is absolutely fine when used in its intended environment, that being the classic 2012(or earlier) style of roblox game. You will unavoidably reach a point where you have too many spawn functions, this is not a thing you can absolutely plan for, this will just become an issue if you intend to make a complex game.
Coroutines obviously have the issue of losing stack trace during errors, however, thats not that big of a deal in the grand scheme of things. Regardless of how bad the error is, you should be able to eventually determine what the issue is without a direct trace back to the error, and you can always test your coroutine function outside of a coroutine to double check.
Naturally, theres a couple workarounds to either of these, namely that being bindable events, though you may not want to make a new bindable event every time you want to run a function, or really use one at all in that capacity.
Personally i’d just stick to coroutines and just figure out issues when they come, and people should definitely be taught how to use coroutines so they don’t keep using spawn() as its grossly out of date for the environment roblox is making for games.
Better question is why doesn’t roblox update all of their old globals to the new task scheduler so we can avoid these problems? Usually their current solution right now is to just implement new alternatives which doesn’t make much sense, since it just bloats the engine.
What if you were to call the function directly instead of firing a bindable? Say you pass a function and after your custom delay is up you decide to call said function.
Yeah thats how i’d imagine someone would do it, I personally do this with coroutines
function module:cowrap(func,...)
coroutine.wrap(func,...)()
end
You could do a similar thing with bindable events in a premade function, so you don’t have to manually fire it every time, just require the module and run the code. I believe thats what the fastspawn module just does, though theres more logic to it than that i hope.