Why is spawn() and delay() bad?

Hello fellow developers,

Been wondering why people avoid using spawn() and delay() badly and say it makes code inefficient, is this true and is there a detailed explanation for this?

spawn() just calls that function on a separate thread. Behind the scenes, it just calls coroutine.wrap() if I remember correctly.

The main reason people don’t like using spawn() is because the function doesn’t immediately run, so they came up with fastspawn() using bindables. With the new change to Roblox’s event system, that fastspawn() method is going to change and may not actually be fast anymore.

2 Likes

Looks reasonable enough, thanks for the explanation, is there a thread that explains it in detail though?

1 Like

I’m trying to look for it but can’t find it right now, there used to be a whole debate in a thread about why you need to stop using spawn() and use fastspawn() instead.

1 Like

This article explains why the classic evil spawn article.

Even Roblox doesn’t want you to use spawn and delay in this article Task Scheduler | Roblox Creator Documentation.

Similarly, avoid using spawn() or delay() as they use the same internal mechanics as wait(). Uses of spawn() are generally better served with coroutine.wrap() and coroutine.resume() of the coroutine library.

3 Likes

spawn and delay are not bad, they are simply two tools with their advantages and limitations. By themselves they do not make the code inefficient. The most important thing is to know how to use them. In a nutshell, you should never cause a task congestion. In a congestion the tasks created with wait or spawn (and are in the middle of the congestion) will take longer to execute because they have less priority. To solve a congestion you can do microprofiling.

I’m afraid you won’t get more information than the official roblox manual. The forum threads are not entirely reliable. Unfortunately Roblox is a closed platform and for licensing reasons (or that sort of thing) the roblox developers can’t give us more details.

This article implies that low priority of tasks created with wait is a bad thing, but it does not explain why. Giving lower priority to a particular task is not a decision that is taken lightly. I’m sure the roblox engineers have a good reason for having done that. And in no way is it malicious on their part.

Also, this article is implying that task congestion is something that just happens and the game should move on. As I mentioned above, this can be solved more intelligently by doing microprofiling.

... In fact, there is no guarantee that they will ever resume at all.
... In worst cases, threads in the secondary queue can get deferred so long that they never even get the chance to run.

This is false. all tasks are solved at some point. You could probably make the task scheduler completely busy and constantly postpone tasks created with wait, but that is unlikely/unrealistic in a real game.

This applies to this context:

To build performant games with efficiency in mind

Creating a 100% high performance oriented game is insane. Even big studios like Ubisoft or Epic don’t do this. High performance and efficiency should be focused on specific places/moments in a game, the rest (which is the vast majority of the game) can be used without problems.

4 Likes