Snap! is kinda slow, but it needs to be compiled and more faster, I used snapinator on scratch project, and its reaaallly slow, Any way to make it faster?
Yeah, lots of. Could you share a link to your project, please?
XML: scratch project boxing over it xml file (converted with snapinator)
why didn't you just save it to the snap cloud and share the project?
I looked at the code and saw a ton of forever loops. Snap lags when there's a ton of forever loops. Try to make it not use as many forever loops, it'll work.
Oh ok , thanks
Make sure you use broadcasts to emulate async forever loops(no takes-very-long-time-sync-or-wait)
But what if all of those loops are necessary?
if I took the time, I could probably take all the loops out and use broadcasting instead.
wouldnt spamming broadcasts have the same effect on lag
it would have less lag than many scripts repeating forever at the same time
just use the warp block
warp{
} :: grey
naw warp block stops all threads and starts them after run.
so warp === lag
What?
Warp stops all the other threads so that this thread gets all the processor time.
1 Like
So the other sprites can't execute animations loop. The whole stage area appears to be freezed or chopppy at best.
1 Like
Yes. "Appears" is the key word. When you use warp, it's because you want to do just computation, not display updating, until the thing you're warping finishes.
One thing that's useful even in a graphics project is to warp some medium-level piece of the program, so for example if you want to draw a whole forest of fractal trees you might warp the drawing of each tree, rather than warp the entire picture.
But sometimes graphics isn't what you're after at all. You want to compute the next move in your chess program or something, and there's nothing to draw until you've finished that computation.
1 Like
I have the same question. Scratch is more efficient than Snap, so I agree that Snap should be faster.
See this video for more information.
I hope you saw that you are responding to a thread from 4 years ago. And the youtube movie is 2 years old. We never saw the code the video maker used.
It is always easy to make code that is in your favor.
There are many factors that play into how scratch is faster. One bug reason is, scratch has a whole team working on it, and it has barely changed since the first version, so they can spend a lot more time optimizing it. Snap is mainly developed by one person, jens, and he tends to add more stuff to snap, which gives him less time to optimize snap.
However, there are also some other unavoidable reasons why snap has to be slower than scratch.
In snap, every script is it's own context. Every script can have it's own variables, scripts can be put into variables to be called later, and you can edit scripts with code.
In scratch, the sprite the script that has been ran in, is the scripts context. The only variables you can use in scripts, are variables for the whole sprite or project, not just the script. Scratch does not allow you to put scripts in variables, and you can't edit the scripts with code. This allows scratch to optimize to not bother with those things, because it doesn't have to.
In snap, you can store anything in lists, text, numbers, costumes, sounds, scripts, sprites, and even other lists.
Scratch can only store text, so it doesn't have to be able to support other types in lists.
I believe scratch and snap should not be compared by using speed, because speed is literally one of the worst metrics to compare programming languages. For example, python is notoriously slow*, yet it's one of the most used programming languages, because it's easy to use, powerful, and has lots to offer. If speed were the only metric, everyone would be using rust, however, that is not the case. Speed is an easy metric to calculate, and people tend to use it to compare things, but it's a terrible metric, because you're not even using any of the unique features of one language, you're only limiting the program to the features of the more limited language (or at least, that's how people tend to compare scratch and snap).
*A lot of people say python is slow, and compared to other languages with specific programs, it is slow, but from my experience, it's fast enough for the tasks I do in it, and I've only ran into one instance where a faster language would be better. And honestly, I can say this same thing about snap. Snap is fast enough to do most tasks that I do.
I love both scratch and snap, and they have different features that make one better than the other. If I were making an online multiplayer project, I would use scratch, because of it's cloud variables (users have created cloud variables in snap, but they're very very prone to hacking, and they're not as easy as scratch's cloud bariables), but if I were creating a project to analyze an image, I would use snap, because of it's ability to get the pixels of a costume without telling the user to go to some external site to convert the image to a text format that can then be inputted into an ask box, and can then be parsed by the program (yes, there are many scratch projects like that).