Why is SNAP! so slow

This is not about a specific project, more about :sn: as a whole. Since SNAP! is coded in JavaScript, shouldn't be able to run at almost the speed of JavaScript program? However, this is clearly not the case. What exactly is the cause of this slowdown?

If you write your program in JS, some of the time goes into interpreting your code -- figuring out the notations and how to carry out each kind -- and the rest goes to what your program says to do.

If you write your program in Snap!, some goes into the interpretation of Snap!'s JS code, but also, a lot goes into the work Snap! does on your behalf in displaying everything and maintaining its data structures full of code and data. If you had to do all that yourself in JS, your JS program would be just as slow as Snap!.

Well snap is not designed to be fast. At least it runs

Yes and no. Other things matter more -- one that's super important to Jens is liveliness, which means that you can edit a script while it's running, and the change will take effect right then. But within the constraints of having it work at all, Jens does put a lot of effort into speeding things up.

So that's where he gets his signature from. Thanks for the quick reply, what you said makes sense.

Snap it's not a JS lib or API. It's a complete IDE, runtime environment and advanced visual language written IN JS. The perceived "slowness" may be inflicted by some design concepts.
Let's look at the microbenchmark - 60.000 iterations of simple test instructions.

speed script pic

It can take as long as 1000 s or just a few seconds in Turbo Mode or "warped".
So, with approriate design, you can make hundreds of calculations per frame and still get decent 60FPS animations.

Can we make that optional? I can do without in favor of speed.

It's not like that. I mean, sure, we could have an option setting that would prevent you dragging a block into a running script, but it wouldn't get any faster -- slower, if anything, because it'd have to keep checking that option setting.

But the entire structure of the evaluator is designed around liveliness. Most importantly, the script you see as a picture isn't a picture of "the real code" somewhere else. The picture is the code. Each block is an object whose properties include both what it looks like (shape, color, title text, etc.) and what it means (how to carry it out). That doesn't horribly slow Snap! down, but it does a bit, compared to compiling the script into some low-level language, or even into machine language.

How does fullscreen compare with running it inside the editor?

It's the same evaluator. Yes, fullscreen avoids the need for redisplay of sprites in the sprite corral, for example, so that helps a little. But almost all the time we deliberately slow down the display cycle so that your project runs at a uniform speed on every computer. WARP and Turbo Mode undo that to some extent.

But, for example, you can speed up programs that use a sprite's pen to draw on the stage by hiding the sprite itself.

Okay. Will the Morphic rewrite have anything to do with this?

Mainly it will affect the amount of memory required for projects. This in turn will help with Chrome crashes. Some things may be faster, too.

well for me a scratcher for 4 years i can indicate that this website is not degisned to be high-speeds or social whatever. ok? ok. kk, got it? alright k.

1 Like

That could be true :thinking:. And I see that is your first post! Welcome to Snap ! (and Snap ! Forums)!

i honestly say that Snap is faster than Scratch is, so I come here when I'm waiting for Scratch to load lol

It depends on the project, but this is nice to hear!

also, the 3.0 version of Scratch had removed multiple blocks. I only joined Scratch 2 months ago, so was not around to know what the 2.0 version was like, but some people have told me about it, and some projects still contain some of the old blocks, which I thought were pretty useful. I didn't see the reason for their removal.

Scratch 3.0 removed most of the "hacks" 2.0 had. Many projects subtly abused some of those blocks and the other blocks were removed for their own reasons. That's why you're here on :snap: where can make literally any block you need.

Which things exactly? I am interested.

Oh, I have no idea. The code is totally rewritten; some things were already fast, but some things were slower than they had to be, and rewriting will speed those up. But I don't have a list of which are which. Maybe Jens can tell you some that he's found.