scratchfoundation / scratch-gui

Graphical User Interface for creating and running Scratch 3.0 projects.
https://scratchfoundation.github.io/scratch-gui/develop/
BSD 3-Clause "New" or "Revised" License
4.42k stars 3.51k forks source link

Memory Leak? #6228

Open griffpatch opened 3 years ago

griffpatch commented 3 years ago

Expected Behavior

Switching back and forth between sprites with 1000's of blocks should not incur ever increasing amounts of memory usage

Actual Behavior

I have two sprites with 1000+ blocks in each - not uncommon for large projects. When scratch is first opened in the chrome browser it can take a moment to switch to a sprite, but scrolling is smooth and all is good. However, if I then switch to another large sprite things are a little less smooth, then switching back to the first sprite things get more laggy... over time things become unbearable and unworkable until I close the tab, or even the browser and begin again. I also note that the memory usahe reported by chrome for the scratch tab goes up by 100MB-200MB every time I switch sprite. (Note the project is not running, and no browser extensions are loaded)

I simply switched back and forward 50 times in my project and it consistently went from 200MB up to 5.5GB and counting. The memory usage then stayed flat at this and does not garbage collect away so would appear it's somehow leaking!

What is unexpected is that reloading the tab does not free up much of the ram used by that tab either... only closing the tab, and opening a new one does the job? What does that mean!?!

Steps to Reproduce

Load up a very large scratch project and switch between heavy scripted sprites (keep the chrome task manager open and keep note of the memory usage). (eg. paper minecraft)

Operating System and Browser

Chrome, windows 10

towerofnix commented 3 years ago

What is unexpected is that reloading the tab does not free up much of the ram used by that tab either... only closing the tab, and opening a new one does the job? What does that mean!?!

FWIW, same experience here on Firefox - for me whatever the memory leak (maybe some cache which is not getting cleared properly?) makes it so successively reloading the Scratch page (e.g. while testing locally-hosted code for a feature/bugfix) will use up memory, and the only way to clear it is to close the tab and open it in a new one.

I haven't noticed this happening so much while switching sprites as when reloading the editor altogether, but the projects I normally work on only have ~200-1000 blocks per sprite, so it might not be so significant there.

griffpatch commented 3 years ago

I would expect this to be a bigger issue than people imagine for laggy scratch experiences, because it is accumulative and persists across changes in url within the scratch website, laptops with small amounts of memory would soon run out (thinking Chromebooks especially). Also, scratchers can spend a very long time within their projects and you just won't see this issue unless you do spend a long time working on a project (unless you have very large projects which manifest the problem quicker)

apple502j commented 3 years ago

Can you open Chrome debugger or something to identify the cause? I tried to do it but my 8GB RAM was not enough to debug the memory leak :P

BryceLTaylor commented 3 years ago

@griffpatch could you link to a project that you can see this issue on?

griffpatch commented 3 years ago

@BryceLTaylor , Try it on this project, switch between the "Player" sprite and the "Manage" sprite and watch the memory footprint go up in chrome task manager: https://scratch.mit.edu/projects/322341152/

Note adroitwhiz has noted that running a profiler in chrome at the same time causes the memory to get freed up lol - but otherwise it just builds and builds!

adroitwhiz commented 3 years ago

What I've noticed:

griffpatch commented 3 years ago

That's interesting - I do know that with chrome dev tools window open things go VERY slow on these project - in the tests I reported I do not open dev tools, instead I open the chrome task manager which reports memory usage too per tab. I then switch sprites and it does not lag anywhere near that long - just a couple of seconds, and memory usage usually increases by just 100MB per switch.