Scratch

My own experience on some of these issues has led to mixed results:

1) I've noticed that using a lot of broadcasts did not slow down my projects at all, as compared to using large stacks.

2) I did not yet notice that loop-execution takes longer the first time. I'm not sure about the java player but am pretty certain, that Scratch-projects are, in fact, never converted to byte-code at all, but interpreted all along. Nonetheless there are many reasons why a script may take slightly longer to execute the first time, especially if it uses resources like costumes or midi-ports which need to be initialized first.

3) I don't think there's any difference in system-resource usage between color sensing and touching-sprite sensing in the Squeak version.

4) I have noticed, that running several forever-loops in parallel will significantly and sometimes spectacularly slow down the execution of a project. Therefore reducing the number of active threads in my experience seems to be the single most effective way to speed up project execution. But there are some catches to this as well. For example, I generally like to trigger sprite movement by a keyboard event. But some users (I think it was archmage) have observed, that a sprite responds more quickly and smoothely if it queries the key-pressed event from within a constantly active forever-loop. So, I guess it really depends on what exactly you want to speed up...

5) The biggest surprise for me was that there seems to be a *huge* difference between the Squeak-version and the online Java-player when it comes to many sprites. In the offline Squeak-version I was baffled to find out that my projects got *faster* if I distributed my code over more sprites, whereas in the Java-player even single-sprite projects that sometimes don't work in the Squeak version at all seem to be doing okay. It is my overall impression that adding sprites 'costs' next to nothing in the Squeak version, but slows down the Java-player.

These are - however - just my impressions from using Scratch. I didn't inspect the source code (yet) to find out about performance profiling of Scratch projects, as I'm generally more interested in cool ideas than in speed-games.

In programs that I've written Loops and BroadcastAndWait have caused considerable slow down because the current script seems to stop executing at the end of the Loop and the start of the BroadcastAndWait to allow other scripts to run and allow for the screen to refresh.

This really depends on what kind of program you're writing as to if any of this is noticeable.