Meta - Performance Optimization

Scratch 3.0 should execute projects as fast or faster than Scratch 2.0. In some places performance is already superior, but we can use this issue to track places where we are seeing bottlenecks. Once a specific performance improvement has been identified an individual issue should be filed and referenced here (meta issue).

Issues

• Procedures (getProcedureParamNames, getProcedureDefinition, etc.)
  • https://llk.github.io/scratch-vm/#141490356
  • http://llk.github.io/scratch-vm/#97272135
• Procedures (“Run without screen refresh”)
  • Example: https://llk.github.io/scratch-vm/#141490356
  • PR: https://github.com/LLK/scratch-vm/pull/406
• Variable getters / setters
  • http://llk.github.io/scratch-vm/#24115792
• Step thread
  • http://llk.github.io/scratch-vm/#26886797
• Touching
  • (Needs minimal example case)
• Turbo mode

Stress Tests

• https://llk.github.io/scratch-vm/#118602500
• http://llk.github.io/scratch-vm/#139193539

[thisandagain]

Not worried about the difficulty, worried about additional code that we need to maintain and test.

[griffpatch]

If you want to see something working pretty well, then try out this 😃

https://griffpatch.github.io/scratch-vm/#105500895

To get this working I had to:

• Fix “stop this script” form terminating threads
• Fix case insensitive broadcasts
• Fix the " " == 0 bug.
• Implement sprite fencing (to stop them going offscreen)

The optimisations I’ve made also make the runtime engine roughly 3 times quicker now.

These changes are in my optimisation/reuseStackForNextBlock https://github.com/griffpatch/scratch-vm/tree/optimisation/reuseStackForNextBlock branch at present.

On 2 February 2017 at 23:47, Andrew Griffin [e-mail] wrote:

Well thank you greatly for taking the time to reply at such length 😃.

That does confirm what I guess I knew, that you were focusing on getting things working fully first 😉. Also of course by not optimising things now you leave the choice fully open to be more easily rearranged and optimised later on… With that in mind would it be best for any optimisations I make to be small in scale for the time being? I could always check in a branch with optimisation tests (larger scale) separately and without pull requests.

Thanks 😃

On 2 Feb 2017 11:36 p.m., “Chris Willis-Ford” [e-mail] wrote:

Thanks for all your work and your thoughts, @griffpatch https://github.com/griffpatch! I agree with your concern about the current performance of Scratch 3.0 but I believe we’ll be able to improve it quite a bit in the future.

In short, the team is aware that Scratch 3.0 isn’t as fast as we’d like but we’re focusing most of our time and effort on features right now. We may occasionally do some performance work when we notice a specific problem – @rschamp https://github.com/rschamp did so in LLK/scratch-gui#61 https://github.com/LLK/scratch-gui/pull/61 today, for example – but the priority right now is to get as much of Scratch 3.0 basically working as we can, as soon as we can. One way to think about that is this: if a large number of people are suddenly unable to run Scratch 2.0 for one reason or another, I’d rather offer them a version of Scratch 3.0 which can run every Scratch 2.0 project, but complex ones run slowly, than a version of Scratch 3.0 which is reliably fast but can’t run all projects.

Another reason we’re not yet focusing on performance is that as we implement new features we’re likely to make occasional large changes to the internals of the VM and other modules, which might change the performance characteristics. For example, preparing the renderer for an external storage module led to a speedup in changing costumes (the old code had always been intended as temporary), and the recent work on the pen blocks led to noticing a way we could potentially reduce the impact of “sprite info” events. It’s possible that we’ll end up removing “sprite info” events entirely, though, so we haven’t yet spent the time to implement that optimization.

All that said, performance is definitely important. On one hand, better performance means that you can run a more complex project (cough @griffpatch https://github.com/griffpatch cough) on a given piece of hardware. On the other hand, better performance also means that a given project can run well on cheaper, older, or lower-powered hardware – potentially opening Scratch to a larger audience.

Some time later this year I expect we’ll be moving from large, sometimes disruptive changes to more detail-oriented work – the 10% of the work that requires 90% of the effort – and we’ll probably put more effort toward performance at that time. We’ll break out the profilers and the whiteboards and figure out if we have to cache this data or unpack that object, or rotate all of the VM’s internals 90 degrees to the left… whatever we need to do in order to get great performance out of the new codebase. As we work toward that phase, we may also do smaller performance passes now and then to keep performance creep under control.

In the mean time, we really do appreciate help from you and others in the community. One of the best things about an active open-source community is that people like yourself and others can contribute to parts of the effort that we’re not currently focusing on (like performance), or where we missed a detail (like pen alpha). It takes a village to raise Scratch 3.0!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LLK/scratch-vm/issues/391#issuecomment-277119582, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbNvpTNludQkjF5T9G1SyppTUZvidNgks5rYmhUgaJpZM4Lqdzb .