WolfCat67 wrote:

jji10 wrote:

As someone not experienced with programming, is there any plus-side to React?

Yes, I'd like to know this too. I only understand Scratch, basic HTML, and basic Python.

Oh, there are definitely benefits to using React. So much so that it has essentially spawned a whole new era in the Javascript world. The problem is that many of these benefits are a little abstract and hard to explain. To help me out, I'm going to use analogies to programming in Scratch to make it a little bit easier:

React is a framework for structuring your code. The benefits that it provides are that it helps to keep code clean, organized, and bug-free. With Scratch, this type of behavior is built-in by default. When you're writing a Scratch program, you can just tell Scratch what each sprite should look like (using the costume editor) and where it should be located (as well as a few other tweaks using the looks blocks), and Scratch draws all of those sprites onto the stage for you.

Javascript, by default, doesn't do this. You can't write Javascript code that says “I would like the webpage to have these HTML elements positioned in these locations”. Instead, you have to manually create and update all of the HTML elements yourself. It would be like if the only way to make things appear on the screen in Scratch was by using the pen blocks. React fills in these gaps. You can write code that tells React “I want these HTML elements positioned in these locations”, and React will figure out which Javascript code to run in order to make it happen.

This thread has been giving React a bad rep, and with many good reasons why. But it's not all bad. React makes development fast and easy, and allows easy updates to made to your code in the future. Implemented correctly, it isn't too slow (except on the first page-load), and it helps keep everything bug free.

The CPU is around 13% to 20% just idle.
The RAM used progressively gets larger while idle. then stays around 80 to 90 MB after some time has passed.
then i made this simple program.

when green flag clicked
pen down
forever
go to (random position v)
change pen (color v) by (10) ::pen
end

and that happened
The CPU is now around 40% to 80%
The Ram Usage increased greatly.

PullJosh wrote:

This thread has been giving React a bad rep, and with many good reasons why. But it's not all bad. React makes development fast and easy, and allows easy updates to made to your code in the future. Implemented correctly, it isn't too slow (except on the first page-load), and it helps keep everything bug free.

It seems people are having a bad React-ion to Scratch 3.0.
that was terrible :|

I think this now mostly has to do with RAM usage. Maybe it's just unoptimized as heck?

walkcycle wrote:

Overall memory and CPU looked the same using the two Scratches. That's promising.

What was the project for the tests?

Using the two Scratch VMs, 3 did better by 5-20% in RAM. CPU varied, but projects were running up to 3x faster in 3. React is definitely suboptimal, but I think that they can make it work.

PullJosh wrote:

comp09 wrote:

The reason why it's CPU intensive is because it's spinning the render code 30/60 times a second.

Surely the renderer could update only when sprites move/change, right? I mean if we're using React…

The renderer does not use React. It does its own thing with canvas/WebGL.

Also, React is best described as a virtual DOM rendering library, not a framework. It only provides the “view” part of the typical MVC pattern. The rest is filled in by other libraries, like Redux in Scratch's case.

—

On the other hand, I honestly don't know why Scratch is using React this way - to render largely static pages with little interactivity (which might/should change in the future). I think one thing they should consider doing is adding a client-side router (react-router) so that page transitions are instantaneous, rather than having to boot up everything again every page load so it's worth using React.

I think the thing we really need to consider is that S3.0 is still in development, and optimisation isn't really going to be something on the list when the memory difference is 1%. I mean, seriously. As for your CPU, well, I think that this is something we're going to have to deal with as Scratch becomes a bigger program, they should still try to keep it optimised though.

I_Rant_About wrote:

I think the thing we really need to consider is that S3.0 is still in development, and optimisation isn't really going to be something on the list when the memory difference is 1%. I mean, seriously. As for your CPU, well, I think that this is something we're going to have to deal with as Scratch becomes a bigger program, they should still try to keep it optimised though.

When a minimal programming app for kids starts eating through your CPU/GPU, it shouldn't be disregarded as “something we have to deal with.”

braxbroscratcher wrote:

walkcycle wrote:

Overall memory and CPU looked the same using the two Scratches. That's promising.

What was the project for the tests?

Using the two Scratch VMs, 3 did better by 5-20% in RAM. CPU varied, but projects were running up to 3x faster in 3. React is definitely suboptimal, but I think that they can make it work.

Yeah. There is still quite a bit of work to do, but in December and January we made some serious improvements to the VM that reduced Garbage Collection (both major and minor GCs), memory consumption, overall CPU utilization, and GPU performance for some tasks. It's a big step in the right direction, but as others have noticed we are burning a lot of CPU in the GUI and blocks that should be fairly straightforward to resolve. We have another round of performance work scheduled in March and I'm fairly confident that we'll be able to get overall resource utilization down to a good place. In some areas we are already handily beating 2.0 performance metrics which is exciting.

One major area we have been investing in is better tooling for measuring (and thus, optimizing) performance. The new VM playground is pretty neat if you haven't seen it:
http://llk.github.io/scratch-vm/suite.html

I suppose as a general comment it seems a little odd to compare a system that has been around for 5+ years to something that is still in alpha. Performance optimization is very often an incremental process, but architecturally the system was designed to deliver to > 2.0 performance from the very beginning. Blaming overall CPU or memory utilization issues on a library like React doesn't really make sense when in the grand scheme of things it is simply a thin layer sitting on top of a much *much* larger codebase. I suppose this argument feels like arguing about what brand of paint we bought for the walls of a house that still needs plumbing and electrical work.

thisandagain wrote:

braxbroscratcher wrote:

walkcycle wrote:

Overall memory and CPU looked the same using the two Scratches. That's promising.

What was the project for the tests?

Using the two Scratch VMs, 3 did better by 5-20% in RAM. CPU varied, but projects were running up to 3x faster in 3. React is definitely suboptimal, but I think that they can make it work.

Yeah. There is still quite a bit of work to do, but in December and January we made some serious improvements to the VM that reduced Garbage Collection (both major and minor GCs), memory consumption, overall CPU utilization, and GPU performance for some tasks. It's a big step in the right direction, but as others have noticed we are burning a lot of CPU in the GUI and blocks that should be fairly straightforward to resolve. We have another round of performance work scheduled in March and I'm fairly confident that we'll be able to get overall resource utilization down to a good place. In some areas we are already handily beating 2.0 performance metrics which is exciting.

One major area we have been investing in is better tooling for measuring (and thus, optimizing) performance. The new VM playground is pretty neat if you haven't seen it:
http://llk.github.io/scratch-vm/suite.html

I suppose as a general comment it seems a little odd to compare a system that has been around for 5+ years to something that is still in alpha. Performance optimization is very often an incremental process, but architecturally the system was designed to deliver to > 2.0 performance from the very beginning. Blaming overall CPU or memory utilization issues on a library like React doesn't really make sense when in the grand scheme of things it is simply a thin layer sitting on top of a much *much* larger codebase. I suppose this argument feels like arguing about what brand of paint we bought for the walls of a house that still needs plumbing and electrical work.

Agreed.

thisandagain wrote:

There is still quite a bit of work to do, but in December and January we made some serious improvements to the VM that reduced Garbage Collection (both major and minor GCs), memory consumption, overall CPU utilization, and GPU performance for some tasks.

Does that mean Scratch 3.0 has its own GC? Why not leave it up to Javascript?

Jonathan50 wrote:

thisandagain wrote:

There is still quite a bit of work to do, but in December and January we made some serious improvements to the VM that reduced Garbage Collection (both major and minor GCs), memory consumption, overall CPU utilization, and GPU performance for some tasks.

Does that mean Scratch 3.0 has its own GC? Why not leave it up to Javascript?

Good question! No … we leave that up to Javascript, but we have to worry about how often the underlying JS engine (e.g. V8 from Chrome) is doing GCs as it can cause “jank” (see: https://developers.google.com/web/fundamentals/performance/rendering/).

The benchmarking/profiling work is really great: https://github.com/LLK/scratch-vm/pull/901

thisandagain wrote:

Good question! No … we leave that up to Javascript, but we have to worry about how often the underlying JS engine (e.g. V8 from Chrome) is doing GCs as it can cause “jank” (see: https://developers.google.com/web/fundamentals/performance/rendering/).

Oh, thanks.

100% support for you.
In my opinion Scratch 3.0 is WAY to child oriented
Also why is the Pen an extension?
Even music blocks?
Scratch 2.0 is the best of all of these (1.4, 2.0, 3.0) in my opinion. It is the right balance between child friendly and programming friendly.

Meowlit12 wrote:

The CPU is around 13% to 20% just idle.
The RAM used progressively gets larger while idle. then stays around 80 to 90 MB after some time has passed.
then i made this simple program.

when green flag clicked
pen down
forever
go to (random position v)
change pen (color v) by (10) ::pen
end

and that happened
The CPU is now around 40% to 80%
The Ram Usage increased greatly.

you should run that script in turbo mode
When i did so it kinda froze my ancientold laptop (bought in around 2006ish- what most kids use for themselves-( where i come from)) (CPU usage went up from 52%( at idle- it runs windows 7 what do you expect) to 73% which is quite a bit if u ask me even for a pentium 4
On my friend's newish (built in 2014, what most schools in my area would normally have) desktop PC, it lagged just a bit (CPU usage went up to 52 from 39(idle- it runs antivirus in the back) on a core 2)
On my current laptop (which, being a gaming model, most people won't have) the CPU usage goes from 12%(idle) to around 22. These numbers are the total usage btw not the usage caused by scratch alone.

when green flag clicked
forever
Eat
Sleep
Scratch
Repeat
end

cloudflame wrote:

100% support for you.
In my opinion Scratch 3.0 is WAY to child oriented
Also why is the Pen an extension?
Even music blocks?
It looks too much like a TOY if you know what i mean
Scratch 2.0 is the best of all of these (1.4, 2.0, 3.0) in my opinion. It is the right balance between child friendly and programming friendly.

Just to keep the thread on-topic – this topic doesn't at all focus on the actual design and functionality of Scratch 3.0 (which most of your post talked about); instead the topic is the technical performance of Scratch 3.0 (versus Scratch 2.0) and the effect that has on users.

Sorry about the image, it didn't load.

This is alot of RAM that Scratch 3.0 takes up, it is alot more compared to 2.0 (no other tabs were opened).

I'm actually kind of worried about 3.0….. Can it be the end of Scratch???

WolfCat67 wrote:

Jonathan50 wrote:

Also, while I agree with your first and fourth suggestions, I don't think it's going to happen since the Scratch Team are working hard on what they have and they've already set a deadline for themselves (planning to release Scratch 3.0 this August).

I don't mind if they postpone it, really. If they can't make it run well before the deadline they've set, then further the deadline to get the work done well.

the new “trim” option for the sound editor…
———————————————————–
edit: the sprite editor is awful and hard to learn… Of Course The Scratch Team Would Do That