The new “run without screen refresh” feature is totally awesome! It's very fast for normal repeats, etc.

Unfortunately, for some scripts, it's faster when I make it non-atomic! As far as a recursive script goes, it's much, much faster when it's running non-atomically than when it's atomic! Remix the project to see what I mean. Running on a new MacBook Pro, it takes 1.457s with screen refresh, and 19.74s without… that's a 13 times difference! Check out this project to see it in action.

I don't know how to change the atmoic-ness of the block once it's made, so I would like a “make atomic” choice in the right-click menu of the define block.
(EDIT: Figured it out, but you need to make it more prominent! )

Also, infinitely recursive blocks freeze Scratch:

define freeze
freeze

2.801 with, 20.039 without. In turbo: 3.258 with, 20.275 without.
Very odd.

Yes: I forgot to mention turbo mode actually slows performance down in this case.

Very interesting - and helpful to know about the performance issue.

Hardmath - can you make a project that demos the performance issue using the smallest number of scripts possible? Perhaps make two identical blocks, one atomic and the other not, and use the timer to track and show the performance of each.

That is essentially what we'll have to spend time doing to find exactly which operation is causing the slowdown, so if you can help us out that'd be great.

Done. Two identical, simple recursive scripts to move n steps forward: one atomic, the other not. The speed difference is dramatic: 10 times more.

Hardmath123
Done. Two identical, simple recursive scripts to move n steps forward: one atomic, the other not. The speed difference is dramatic: 10 times more.

Ah, excellent! The background text seems to contradict the notes though?

Huh? There's background text?

EDIT: Removed it. I added it, then removed it because project notes seemed more natural. Apparently that version wasn't saved…

Tests with a non-recursive script which simply repeats a blank action 3600 times:

Hardmath123
As far as a recursive script goes, it's much, much faster when it's running non-atomically than when it's atomic! Remix the project to see what I mean. Running on a new MacBook Pro, it takes 1.457s with screen refresh, and 19.74s without… that's a 13 times difference! Check out this project to see it in action.

You're right.

Note that the “Run without screen refresh” option was added recently, as a replacement for the “all at once” block.

Recursive procedures currently run in a sort of “turbo mode”. The screen isn't refreshed until the recursion is finished. (Actually, if the recursion takes a long time, the screen is refreshed a few times per second so the user can see that progress is being made.)

This is different from loops, which refresh the screen after each iteration. Recursion should be handled more like a loop, with a screen refresh done on each recursive call unless the “Run without screen refresh” box is checked.

But you've also found an implementation flaw, because “Run without screen refresh” should not slow down recursive procedures. I will look into that.

– John

Hardmath123
Also, infinitely recursive blocks freeze Scratch:

define freeze
freeze

Although this makes Scratch very slow to respond, it does not entirely freeze. If you hold down the stop button for a few seconds, it should eventually stop. Does that work for you?

– John

Hmm, it does stop after 20-ish seconds, which is way too long. In my opinion, a recursive block should be handled like a loop, with a slight delay between calls. This way we get to watch the recursion taking place in real time (in recursive drawings), and are blocked from freezing/slowing down Scratch with infinite recursion. Atomic blocks should obviously speed up the recursion. Something like this:

when I receive evaluate block:
if (current block = block to evaluate) and (not atomic)
| wait 0.01 seconds
evaluate block to evaluate

This shouldn't be too confusing to new users either, as it is very intuitive.

@Hardmath - Where is this “run without screen refresh” feature of which you speak? I can't seem to find it.

It's at the bottom of the options when creating a custom block.

Thanks scimonster!!!

Hardmath123
In my opinion, a recursive block should be handled like a loop, with a slight delay between calls.

I agree… and now it does exactly that. Here are some notes:

A recursive procedure call (without “do without screen refresh” checked) now behaves like a loop. That is, it yields control (allowing a screen update) before each recursive call, just as a loop yields control before looping back. Thus, the following scripts give equivalent behavior:

forever
turn 15

define spin
turn 15
spin

In fact, you can even combine either version with a “forever move 10” to move the sprite in a circle.

This change also means that accidental recursion won't appear to lock up Scratch.

Note that Scratch does not currently support Logo-style “tail recursion optimization”, so the recursive version of the loop above gradually builds up a long stack of procedure calls. Thus, in Scratch, recursion is not a good way to express an infinite loop. However, Scratch's recursion is very efficient, so if you only need to repeat some operation a few thousand of times, a recursive solution will give performance similar to the equivalent loop. You should use recursion where that's the most natural way to express some algorithm (e.g. drawing trees or fractal designs) or when you want to demonstrate how recursion works.

If you check “do without screen refresh” on a recursive procedure, it only updates the screen twice per second while that procedure is running, so you get an effect similar to turbo-mode. This can result in stunning performance when creating complex drawings or graphic effects.

What's the difference between “do without screen refresh” and turbo mode? They both allow code to run faster by doing more computation between screen updates. However, turbo mode affects all the scripts and you have no control over when the screen gets updated. Using “do without screen refresh” gives you better control over when the screen is updated. As long as your computation takes less than about half a second, it will get done entirely “offscreen”, without any screen updates. This opens up possibilities for fast, flicker-free drawing of simple shapes, 3D wireframe models, trees, fractals, etc.


Enjoy!

– John

Recursion + “run without screen refresh” + pen gives stellar performance. I've clocked it at around 800,000 operations per second on a Mac Book Pro. It opens up all kinds of new possibilities. This project would have never been possible without it:

The Magic Tree

(A lot of the 3D stuff people are doing is really cool too.)

superscripts wrote:

Recursion + “run without screen refresh” + pen gives stellar performance. I've clocked it at around 800,000 operations per second on a Mac Book Pro. It opens up all kinds of new possibilities. This project would have never been possible without it:

The Magic Tree

(A lot of the 3D stuff people are doing is really cool too.)

Good to hear, superscripts! Since this issue has been fixed, I'll close this thread.