Greetings, 10+ years Scratch user but day one here..
I made a test to compare Snap's processing speed to Scratch, a simple project that continuously spawns a turtle sprite as clones which chase the mouse cursor around. I made the same project in both Snap and Scratch.
In Snap once I hit around 50-60 clones their movement begins to lag pretty badly
In Scratch I can hit the 301 clone limit with almost zero visible lag
So I'm assuming I'm doing something wrong in my Snap code, please help!
This is a @Jens question, but here's what I found out playing with your code: It does much better without the WARP blocks, and with Turbo mode. Without Turbo, you can see that a lot of the effort is going into animating the scripts with the running-now halo and the clone count.
Thanks so much for replying! Unfortunately I get different results with that fix (old laptop). That got me up to about 160 clones before the lag got unbearable. So the only way Snap can compete speed-wise with Scratch's selective Turbo ("run fast" option for custom blocks) is to run the entire project in Turbo mode? I was excited to see the 5000 clone limit (compared to Scratch's 301) but if I can only push half as many clones simultaneously with Snap as Scratch and only in full Turbo mode, a 5000 clone capacity doesn't help much.
Not bagging on Snap btw. I know it has capabilities that Scratch doesn't and every project isn't about hordes of AI-driven clones. I also know that Scratch was recently updated and received a top end boost and I barely know what I'm doing here. But I'm an experienced Scratch user, I need some kind of yardstick by which to compare the top end capabilities of the two platforms and right now this is what I have.
This really isn't my kind of project -- I'm more about text than graphics -- but Jens does run projects with thousands of clones. He should be waking up soon, if I'm computing the time correctly; we'll see what he has to say.
Thanks again! I narrowed down the problem..
I'm using a Tick broadcast inside a Forever loop inside the stage. In Scratch you can coordinate this with custom blocks set to "run fast" (which I believe is like Snap's warp block) inside Sprites to create very complex projects that run fast with zero lag. The problem I'm having appears to be with that broadcast. If I put the broadcast inside a Forever loop by itself the sprite never reacts even when I put ll that code inside a Warp block. It feels like the broadcast is repeating too fast? But slowing it down with a Wait 0 block (or oddly enough putting it inside a Warp block) gets a reaction from the Spite but I'm thinking this is creating the lag?
I'll rig up some timers and do some testing to see if I can get a clearer picture on what is happening.
By the way, I added a test feature (press T) that runs the clone code inside a Forever loop rather than off the Tick broadcast. Suddenly I could push 400 clones around the screen with no lag. So it sure seems like Snap is fastest, I jut have to figure out how to get that Tick broadcast synced correctly.
Actually, why do you need the tick signal? If you just have a loop generating clones, each time through the loop it'll let all the other sprites run. If you put the CLONE block inside a WARP, the clone will be made, but it'll never get to run its WHEN I START AS A CLONE.
You seem to be looking at it in the scope of this project which is not a real project but rather a speed test, The tick broadcast is a timing system used to sync all actions while maintaining performance. In simple projects you can often get by with closed parallel loops running in synchronicity but in complex projects you need precise serial loop control so that bullet clone A doesn't fly through wall B because B's closed loop just happened to be out of sync during the collision check.
It was developed at Scratch by Griffpatch, one of the best coders we've ever had and taught in his tutorial studio. Or you can just look at the code in his personal projects such as his multiplayer Terraria and see expanded variants that used staged ticks, etc.
I'm sure you are familiar with trying to explain the virtues of something to people who don't use it. In my experience that is commonly the issue with this system, too
OK. It'll take me a while to wrap my head around this.
One disadvantage of our new forum is that I've really stopped paying attention to Scratch AT, so I have no idea who the champion Scratchers are any more! And I guess they don't necessarily find out about Snap!. :~(
Having a stranger edit my forum posts for their own personal needs without my permission is a huge problem for me. I put up with enough of that crap at Scratch over the last decade. I can't believe it happened in my first post here? Yeah, yeah, I know, you had great intentions. So great that mine don't matter, right?
Wrong.
It would be for me too, if he (@bh) actually edited your posts. He did not. He simply split the posts into a new topic, which makes since, given what was happening with it. It started as a genuine question about lag in SNAP! and Scratch, then quickly degenerated into obscure connections between Scratch and Epstein. Bh even explained why he did it, too:
I hope you don't go! Your projects in Scratch look really cool, imagine what you could do here!
Scratch has faster rendering, but I believe the internal Snap! VM is faster, and generally better, when it comes to working with large amounts of data and general calculations.
To study the original performance problem, i made test case project:
Stage is populated with given count of clones (300). Then 60 iteration of certain action (e.g. "move 5"), for every sprite, is performed. Total time is measured. Action is performed directly by loop or by multiple broadcast.
Simple loop took ~1s, as expected.
Broadcast version behave strange and in-deterministic. It took 10-20s to complete and violates requestAnimationFrame timeout constraints. Browser log is filled by "[Violation] 'requestAnimationFrame' handler took NNN ms" with values 100-200 ms.
It seems that broadcast processing is not consistent nor atomic by any means. Single message handling can be spanned for multiple frame for different clones. Also performance penalty of thread/process switching, relative to sprite count, seems to be high and non linear.
