ScratchData LogoScratchData
Back to _nix's profile

broadcastless forever & even-yield perf tests

_N_nix•Created November 26, 2021
broadcastless forever & even-yield perf tests
2
1
46 views
View on Scratch

Description

More performance tests! Full disclosure: the two new modes are slower than all-at-once "wait until" (but still faster than sequential broadcasts), so if you're looking for something more efficient for your exciting new high-clone 60fps Galaga remaster, you won't find it here. :P === Broadcastless Forever === This approach completely skips out on *ever* starting new scripts, besides at the very beginning—it doesn't use any broadcasts at all. (The one broadcast used to launch it would be replaced with "when I start as a clone" in practice.) Instead, the "wait until target ID = my ID" script is running for every clone, all the time, under a forever loop. The final clone of a cycle is in charge of resetting the target ID back to 1. === Even Yield All At Once "wait until" === This is a remix of AO1-"wait until" which is deliberately slower and attempts to explain the difference in speed between the approach it's based upon and Broadcastless Forever. It forces Scratch to yield from the same number of scripts for every tick within a cycle/frame, using an additional "wait until" at the end of the main receiver to keep the script active until the whole cycle is complete. Basically, these approaches show that the primary lag in this iterating-over-clones objective is derived not necessarily from the individual blocks being executed, but rather from the internal overhead of execution for each script in the first place. In both of the new examples, there's a constant number of scripts running every tick (equal to NUM CLONES, plus one each for the main control and tick counter scripts). In Sequential Broadcasts, it's the same number of scripts executing every tick, but with the additional overhead of starting and ending each of those scripts every tick as well. In All At Once "wait until", it's progressively *less* scripts running every tick: each tick, one of the NUM-CLONES scripts ends, as its "wait until target ID = my ID" condition becomes true and it runs its side effects (including progressing target ID to the next clone ID). Halfway through a frame, only NUM CLONES / 2 scripts are active; by the end of the frame, only one script remains. Then the next frame restarts with all NUM CLONES scripts active again (and progressively counting down each tick, just as before). In effect, this (theoretically) means AO1 "wait until" outpaces its even-yielding competition by greater amounts as more clones are involved—because it'll spend a greater number of its ticks with fewer scripts active. In practice, this slope seems to be very much in favor of AO1 "wait until" even at relatively low numbers of clones. On my device, at up to 6 active clones, Broadcastless Forever remains distinctly faster than AO1 "wait until"; at 15 active clones, there's a clear favor towards AO1, and (proportionally speaking) the gap only increases as more clones are involved. (Actually for some reason the gap seems to cap at about 100% speed increase from the two even-yield approaches to A01 "wait until". I'm not exactly sure why that is!)

Project Details

Project ID607612067
CreatedNovember 26, 2021
Last ModifiedNovember 26, 2021
SharedNovember 26, 2021
Visibilityvisible
CommentsAllowed

Remix Information

Parent ProjectView Parent
Root ProjectView Root