I'd already created a topic with this name, but that turned into a conversation about how clones can respond to broadcasts and it would be unreasonable to bring it back.
I still didn't find what “wait 0 seconds” actually did(I've checked the wiki).

Could someone explain?

As far as I know it doesn't really do that much, it adds the tiniest of delays (the time for the block to execute) and isn't really that needed.

Ok I need to give some context:

I had a script that looked roughly like this:

…and this was very slow. I remembered that adding a “wait 0 seconds” block is supposed to fix this, so I inserted it after the minor counter increment. This fixed it. Why?

In the previous post two people(Scratch-Minion and RokCoder respectively) said:

“Wait 0 seconds” cedes execution so that any other scripts that are waiting run before execution returns to the next block/statement after the wait block.

Only one Scratch script can ever run at a time and they take turns.
“Breakpoints” where other scripts get a turn include each time we reach the end of a repeat block or if block.
* Edit: Not if block (as RokCoder noted below).

(I don't think “breakpoints” is the correct technical word).
* Edit: “Yield” is the word I was looking for as RokCoder noted below.


“Run without screen refresh” for custom blocks is used to override this behavior.


So in your project, the “Wait 0 seconds” somehow allows the code that increments the variable to be run as often as required.

and

@Scratch-Minion is spot on. I just wanted to clarify a few things.

The term yield is more commonly used than breakpoint for this. Not a particularly important point but, as SM had suggested the term might not be correct, I thought I'd throw that in.

As far as I'm aware, Scratch doesn't yield at the end of an if block. The places it will yield are:
end of any loop (forever, repeat, repeat until)
each iteration of a wait until (as this is effectively a loop)
at a stop all (for obvious reasons)
after a broadcast and wait
at a wait (again on everty iteration until the required time has elapsed)
The above list doesn't apply to non-refresh custom blocks as they are designed not to yield.

If I've forgotten anything, I'm sure someone will add to the list

However I needed further clarification.

The “wait 0 seconds” is just a super short “wait” block, it allows other scripts to run, if it wasn't there, other scripts might not have enough time to react to each “script” of the 1024 “scripts” inside of the repeat blocks.

DANISON wrote:

The “wait 0 seconds” is just a super short “wait” block, it allows other scripts to run, if it wasn't there, other scripts might not have enough time to react to each “script” of the 1024 “scripts” inside of the repeat blocks.

You haven't explained the correlation between the two(or four, I can't tell) facts.

Think of Scratch as a stop motion animation being filmed. Say you have several sprites and all the sprites have scripts running which control their movement something like

The scripts look like they are all running at the same time (because all the sprites move at the same time) but they are not. The scripts inside the loops run one at a time, moving each sprite 2 steps and then waiting, just as the animator moves all their models a little bit one at a time. When all the animators models have been moved he takes a picture and repeats the process of moving the models. In Scratch, all the scripts should execute and be waiting when Scratch “takes a picture”, this happens 30 time a second. A wait (0) block will simply cause the script to wait at that point until the next frame.

This should demonstate

The wait (0) causes the repeat loop to only execute every other frame, so i will be 150ish. If you take it out, i will be 300ish.

Hope this helps

Okay, but that's not what happened in my case―my script ran faster when I added the “wait 0 seconds” block in it(I know this for certain), as explained by Scratch-Minion and RokCoder(albeit obscurely).

Weneedto wrote:

Okay, but that's not what happened in my case―my script ran faster when I added the “wait 0 seconds” block in it(I know this for certain), as explained by Scratch-Minion and RokCoder(albeit obscurely).

Oh ok. I'm not sure then. When you put the wait(0) at the end of the repeat loop (in my script) instead of the beginning it then has no effect. I can't seem to recreate a slowing of the script though. Have you tried your project in Scratch 3, Maybe it's something to do with Scratch 2 or Flash player?

Sometimes it's possible that Scratch will try to run too much at a time, especially in turbo mode.

I don't know much about the internal workings of Scratch, but here's a guess:
In turbo mode, Scratch may try to run the contents of each loop multiple times in one frame. If Scratch decides the contents of loop B multiple times but it takes longer than 1 frame to run, then it could cause lag because running the frame takes too long. The lag could slow down Scratch to the point it is faster to force Scratch to run the loop once per frame without lag. If the time it takes to run loop B varies then it could especially be run more times than can be fit in a frame since Scratch can't tell how many times it can run it.

Usually instead of using turbo mode like I think you are doing, I like to use no refresh blocks which offer a more controlled method to running things quickly.

gor-dee wrote:

When you put the wait(0) at the end of the repeat loop (in my script) instead of the beginning it then has no effect. Have you tried your project in Scratch 3, Maybe it's something to do with Scratch 2 or Flash player?

Huh, well, I'm fairly certain I put the “wait 0 seconds” block after the last block within a loop(which was a variable incrementer)

My scratch project won't work in scratch 3 because of the way the <touching color> boolean is changed.

imfh wrote:

Sometimes it's possible that Scratch will try to run too much at a time, especially in turbo mode.

I don't know much about the internal workings of Scratch, but here's a guess:
In turbo mode, Scratch may try to run the contents of each loop multiple times in one frame. If Scratch decides the contents of loop B multiple times but it takes longer than 1 frame to run, then it could cause lag because running the frame takes too long. The lag could slow down Scratch to the point it is faster to force Scratch to run the loop once per frame without lag. If the time it takes to run loop B varies then it could especially be run more times than can be fit in a frame since Scratch can't tell how many times it can run it.

Usually instead of using turbo mode like I think you are doing, I like to use no refresh blocks which offer a more controlled method to running things quickly.

Actually, the speed varied time to time in the first times I ran it-but I think that was to do with clones.

Turbo mode made no difference when used. I was running the script at normal speed. I can't remember if running the script on turbo mode without the “wait 0 seconds” block increased performance.

Ok, your explanation is somewhat helpful, but I was asking for what Scratch-Minion and RokCoder meant by “yield” and how that relates to the script running faster.

I think you need to share a project where including it shows the effect you describe. Keep it as simple as possible.

When Scratch runs scripts, it only runs one script at a time. Usually each script is run once per tick/frame. When a script finishes running it ‘yields’ and goes to the next script that needs to be run. Yielding is just the term for when Scratch stops running one script and runs another. The wait 0 block forces Scratch to yield.

As my previous post said, wait 0 might force Scratch to yield instead of running more than it can handle nicely in one frame. I don't know how Scratch decides to yield though so that could be wrong. You will probably need to create a simplified project reproducing it if you want a more solid explanation.

Maybe this might explain why you script ran faster?? https://scratch.mit.edu/projects/19246070/#editor

gor-dee_test wrote:

Think of Scratch as a stop motion animation being filmed. Say you have several sprites and all the sprites have scripts running which control their movement something like

The scripts look like they are all running at the same time (because all the sprites move at the same time) but they are not. The scripts inside the loops run one at a time, moving each sprite 2 steps and then waiting, just as the animator moves all their models a little bit one at a time. When all the animators models have been moved he takes a picture and repeats the process of moving the models. In Scratch, all the scripts should execute and be waiting when Scratch “takes a picture”, this happens 30 time a second. A wait (0) block will simply cause the script to wait at that point until the next frame.

This should demonstate

The wait (0) causes the repeat loop to only execute every other frame, so i will be 150ish. If you take it out, i will be 300ish.

Hope this helps

Hmm, maybe. Usually when one does loops like that, the counter will zip up into the 6 digits within a fraction of a second…

Weneedto wrote:

Okay, but that's not what happened in my case―my script ran faster when I added the “wait 0 seconds” block in it(I know this for certain), as explained by Scratch-Minion and RokCoder(albeit obscurely).

Your computer probably lagged when you did it without the wait block. The wait block gave the computer time to “think”. This means that the computer ran the script lag-free.

gor-dee_test wrote:

Maybe this might explain why you script ran faster?? https://scratch.mit.edu/projects/19246070/#editor

Very nice project for testing lag. Thanks

Perhaps I'm mistaken and wait 0 seconds improving performance was due to it throwing off the existing clones; I tried to replicate the performance effect(without clones), and waiting 0 seconds didn't make a significant difference, and if it did, it was negative.

With that in mind, what is a practical use of “yielding”?