Event system is slow with simple program

[8119436437056971]

#

Expected Behavior

Two sprites sending 'ping', 'pong' in turn. Should be quite fast, 100k or more events per second.

Actual Behavior

See screenshot. For a very basic script, when wait(1) and set variable (result) to (counter) are disconnected, the counter increases by prox 30 per second. When the disconnected blocks are added to first script, the speed is increased to expected number.

Steps to Reproduce

We have seen the behavior today in school on Raspberry 4, bullseye. Reproduced now on a win10 laptop. Just edit the scripts and start.

Operating System and Browser

Rasperry 4, bullseye, chromium Win 10, firefox 123.0

[CST1229]

I'm pretty sure this is intentional behavior, where recursive broadcasts wait 1 frame.

[8119436437056971]

I'm pretty sure this is intentional behavior, where recursive broadcasts wait 1 frame.

Interestingly, when adding these two statements to end of first script, the counter per second numbers rises from around 30 to 143k = 143.000. When always waiting 1 frame for this 'recursive broadcast' structure, this great increase can't be explained.

On RPi4, today we got around 14 per second when these two statements disconnected, and 10k to 14k with these statements added. Eight teams of kids worked on this task.

We run this sort of program since a few years as a sample for sending events. On RPi 1, A, scratch 1.4 we got counter values of around 22. Quite slow. But this was 10 years ago. On RPi 3, scratch 2 we got much higher numbers, I remember around 10k. On RPi 4, scratch 3 half a year ago we had stable high numbers. On RPi 4, scratch 3 quite current version, we found this strange behavior.

[griffpatch]

I can confirm this slightly off behaviour. If you replace the wait 1 with a "forever (show)" then you get the expected behavior of 30 updates a second where the events are synched with the framerate (as per scratch runtime rules). If you have a 'wait 1', then the update rate is super fast (as expected because there are no screen updates queued up to sync the thread iterations with). However, if you don't have the wait block, then something weird happens and the execution is slowed down as if there were screen updates at play.

I can note one other curiosity... Try adding a STOP ALL block after the wait 1. After a second running uber fast, rather than stopping, the program then continues to run, but slowly once more lol.

On Tue, 27 Feb 2024 at 20:23, 8119436437056971 @.***> wrote:

I'm pretty sure this is intentional behavior, where recursive broadcasts wait 1 frame. Interestingly, when adding these two statements to end of first script, the counter per second numbers rises from around 30 to 143k = 143.000. When always waiting 1 frame for this 'recursive broadcast' structure, this great increase can't be explained.

On RPi4, we got around 14 per second when these two statements disconnected, and 10k to 14k with these statements added. Eight teams of kids worked on this task.

We run this sort of program since a few years as a sample for sending events. On RPi 1, A, scratch 1.4 we got counter values of around 22. Quite slow. But this was 10 years ago. On RPi 3, scratch 2 we got much higher numbers, I remember around 10k. On RPi 4, scratch 3 half a year ago we had stable high numbers. On RPi 4, scratch 3 quite current version, we found this strange behavior.

— Reply to this email directly, view it on GitHub https://github.com/scratchfoundation/scratch-gui/issues/9524#issuecomment-1967529833, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTM3PTPR2ROQOKOFLJHV43YVY6FJAVCNFSM6AAAAABD4XW3G2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGUZDSOBTGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>