run project(with forever block) causes high CPU usage in Chrome

[MaggieLu]

Expected Behavior

Lower CPU usage in browser when running a project with a forever block

Actual Behavior

When running a project which contains a forever block and few other blocks, the CPU usage is always around 80%. At the same time, if I do other actions (e.g. switch sprites, switch block categories in the toolbox), the CPU usage can be higher than 95%. (It reaches 100% once occasionally, which make the browser crashes... )

Steps to Reproduce

1. Open Chrome performance monitor;
2. Drag following blocks:
   
3. Click green flag;
4. Switch block categories or switch sprites

Operating System and Browser

Windows10 Chrome

[TheLogFather]

This is a consequence of the way Scratch schedules script execution when there are no (potential) changes to anything on-screen.

In that case, you're asking Scratch to do 'pure computation', and it doesn't need to waste any time trying to update any on-screen changes, so it runs scripts as if it's in turbo mode.

As an example, create the following:

when GF clicked
set [counter v] to [0]
forever
change [counter v] by (1)
end

When the above is run as the only script, you'll find counter increases very rapidly – and switching to turbo mode makes no difference (because it's already running at full speed).

If you create another script that changes something on-screen (e.g. moves a sprite) within a forever loop, and make both scripts run concurrently, then you'll find that counter only changes by about 30 per second (unless you have turbo mode on).

---

I do think it'd be nice if Scratch could be a bit more forgiving here, though...

It's actually a bit counter-intuitive that a project which tries to work in a more event-driven way (i.e. only makes changes to sprites, etc., when it detects some change in user interaction) ends up sucking up more CPU than one which has a loop that continually makes 'non-changes' to a sprite (e.g. switching costume to the costume it's already on).

Perhaps it could only run at full speed when it detects a block that sets/changes a variable? (i.e. when the script really is doing some kind of 'computation'.)

OTOH, given that we have the non-refresh option, is there any need for this auto-switch-into-turbo-mode behaviour at all...?

[godmar]

I am new to scratch and just noticed this phenomenon as well. As soon as you turn on practically any Scratch program, your laptop's fan will kick in. Based on a quick analysis of the code it appears that Scratch is aiming for 75% CPU usage, which results in the 80% you and also I are seeing.

I am somewhat surprised by this design choice: at this amount of CPU utilization, power consumption goes up drastically. Many scratch users are elementary school students whose Chromebooks are used on battery power when they use them at their desks. Moreover, some students forget to plug them in when they return them to the shared rack. I would expect that running any Scratch program over significant periods of time will drain the battery quickly.

General purpose OS (and also most virtual machines) enter an idle state when there are no events for a program to be processed. Unfortunately, for the 2 programs shown above, which contain infinite loops, this situation will never arise. In real-world programming, writing code like for (;;) if (touching()) do_something(); would be considered a defect called "busy waiting for an event" - but this appears the programming style that Scratch expects when predicates such as "touching" are being used.

Fortunately, Scratch does get it right when event blocks (When ...) are used; however, it's still easy for loops to hide in a Scratch program - for instance, a "wait until touching()" causes the program to become CPU bound.

I can see at least 2 ways of addressing this issue. First, provide more event blocks for commonly used predicates that cause this phenomenon, e.g. "When touching() ...". The scratch team could analyze the code base of shared scratch programs to see which ones are most commonly used. This approach would however require changes to the user code and increase the size of the language.

Second, the VM could optimize block combinations such as wait until touching(sprite) and suspend the calling thread until touching(sprite) becomes true (and internally signal touching(sprite) with an event rather than having the calling thread poll for it as the current implementation appears to do.) This optimization approach would have the advantage that it wouldn't require changes to the user code; because of Scratch's simplicity, it may be feasible to implement this easily for common cases, e.g. if the boolean predicate that's tested by wait until is a simple touching(). Again, an analysis of existing programs may be required to see how often these simple cases occur to see if this optimization is worthwhile.

Unfortunately, the example posted in this thread for(;;) if (touching()) move() would already not be caught by trivial analysis; it would first require transformation into the equivalent for(;;) { wait_until(touching()); move() }.