Slowness of Loops?

One thing to watch for in Scratch is using what I call serial vs. parallel loops. By that I mean, a lot of people use multiple When Green Flag Clicked blocks in the same sprite's code. This can create confusing errors and make long code hard to debug because you get confused over what part of the code is being executed at any given moment. This would be parallel coding.

I encourage people to write all (or at least most) of their sprite's code into a single, long block. It is far easier to make long or complicated code work and to find errors. I call this serial coding.

In fact, it is a good idea to use as few When Green Flag Clicked blocks a s possible because too many will confuse Scratch. Use broadcasts for everything except the main loop.

This is called a race condition. It's really easy to create them in Scratch, since it is easy to create loops.

Multi-threaded programming used to be a "hard" topic for advanced programmers. Scratch makes it easy for kids to do it! But it doesn't provide vital tools like semaphores or locks, which other languages that do multi-threading have.

The solution is to reduce the number of loops. Instead of three or four different loops, try to combine the actions into one big loop. It's possible to still "subroutine" out using broadcasts, but at least control the flow from one loop. Then you won't make yourself crazy trying to debug race conditions.

One student was going crazy with debugging his program that had lots of independent loops and used "on foo key pressed". He combined his user interaction into one big loop checking "if foo key pressed", and got rid of some of the indepenent loops doing sensing stuff, combining them with his loop that checked for user interaction. The game ran MUCH faster and the race conditions stopped.