TL;DR
A single tab trying to load a Scratch project used up 14GB of RAM, so Scratch's memory management has to be improved.
______

Since a long time, loading scratch projects that have a lot of assets are very heave in terms of memory, here is an example –

I tried loading a project on my 2.5 month old laptop (MacBook Air, M1). It has 16 GIGABYTES of RAM, which is nearly twice as much as the average amount of memory Scratchers have (8), and some may even be using 4GB of RAM, or mobile devices with even 2!

https://scratch-mit-edu.ezproxyberklee.flo.org/projects/46130596/ is a project, which, I'm not lying, when I tried loading it, it used up 14 GIGABYTES of RAM, which is INSANE for a Scratch project, I know that it may have a lot of assets, but 14 is so much that my Mac instantly told me that it was running out of memory, and closing this tab may improve responsiveness.

It also had to utilize the SSD for memory, about 3GB of what had to be written to memory, was written to the SSD, and a lot of Scratchers still use HDDs (hard disks), which means their devices would become insanely slow trying to use 3GB of HDD as memory. I restarted my laptop, fresh and clean with no apps open, I open up my default browser (Safari), and I try loading this project, the same thing happens! 14 GIGABYTES of RAM was being used up by this individual tab, excluding the OSs memory!

16 GIGABYTES of RAM isn't what the average Scratcher has, as I said earlier, some may even be using 2 or 4. So can the devs, somehow improve memory management of Scratch projects? A Scratch project using up 14GB of RAM with no other programs/apps/tabs/browsers open (and without looking at how much the OS is using), is not a small thing, this has to be fixed. A lot of projects like these exist, instead of doing something to the projects, somehow can you try to improve how the scratch-gui / vm handles these big projects?

Now I know, you must be thinking,
“Chiroyce, there might be many assets in that project, that's the reason, we can't do anything about it!”,
well yes, but we have to do something, like compress assets or something. Please address this issue ASAP.

Vadik1 wrote:

The thing you haven't mentiond is how forkphorus has a really good memory usage. Using forkphorus I'm able to load and view that project without any issues on a phone which when no apps are running on average has 2 gb of free ram.

Wow! It literally only used about 700MB of RAM on forkphrous, thanks for letting me know! TurboWarp is still the same though, does anyone know why?

support, this is actually ridiculous, and scratch's current system is a terrible way of handling assets in memory. it would be better to load and unload assets as they're needed, similar to how unity, unreal, or pretty much any respectable game engine out them. this might take a bit of work, but it really should be done since this kind of thing is pretty much essential for something like this.

Support.
The thing you haven't mentiond is how forkphorus has a really good memory usage. Using forkphorus I'm able to load and view that project without any issues on a phone which when no apps are running on average has 2 gb of free ram.

Chiroyce wrote:

which is nearly twice as much as the average amount of memory Scratchers have (8)

jokes on you i have 48 GB of RAM
—-
I support as this is literally ridiculous. 14 GB??? Something is wrong with Scratch, and it seems like this would literally crash my iPad.

Vadik1 wrote:

Support.
The thing you haven't mentiond is how forkphorus has a really good memory usage. Using forkphorus I'm able to load and view that project without any issues on a phone which when no apps are running on average has 2 gb of free ram.

Wow! It literally only used about 700MB of RAM, thanks for letting me know! TurboWarp is still the same though, does anyone know why?

kccuber wrote:

I support as this is literally ridiculous. 14 GB??? Something is wrong with Scratch, and it seems like this would literally crash my iPad.

Not really, Safari for iPadOS automatically closes tabs that take too much memory, no matter how much you try, it simply won't load the project. I do NOT know about Chrome though… but still, it's dangerous.

Chiroyce wrote:

Vadik1 wrote:

Support.
The thing you haven't mentiond is how forkphorus has a really good memory usage. Using forkphorus I'm able to load and view that project without any issues on a phone which when no apps are running on average has 2 gb of free ram.

Wow! It literally only used about 700MB of RAM, thanks for letting me know! TurboWarp is still the same though, does anyone know why?

kccuber wrote:

I support as this is literally ridiculous. 14 GB??? Something is wrong with Scratch, and it seems like this would literally crash my iPad.

Not really, Safari for iPadOS automatically closes tabs that take too much memory, no matter how much you try, it simply won't load the project. I do NOT know about Chrome though… but still, it's dangerous.

google chrome on ipad do the same thing.

support, scratch froze my computer at one point (actually, the tab was turbowarp, but still)

Chiroyce wrote:

twice as much as the average amount of memory Scratchers have (8)

jokes on you I have 15.4 Gibibytes of dedotated wam RAM or something

Scratch should definitely try to unload things it isn't rendering when your device runs low of memory at least. Frame-by-frame animations are basically unwatchable on devices with little RAM.

I have 4 GB of RAM and things were getting really crazy really fast so I closed the tab on that project.
Who knows what would have happened to by laptop if I hadn't, (and who knows what has already happened to other people's computers), so I support.

Raihan142857 wrote:

Who knows what would have happened to by laptop if I hadn't

house fire.

potatophant wrote:

Raihan142857 wrote:

Who knows what would have happened to by laptop if I hadn't

house fire.

I have 4 GB of RAM and 3.6 GB of free disk space. It took Chiroyce 14 GB of RAM for the project to load. I am honestly quite interested in what could happen (either something mundane will happen, like my computer restarting, or something crazy can happen) but I don't want to risk it.

Raihan142857 wrote:

I have 4 GB of RAM and 3.6 GB of free disk space. It took Chiroyce 14 GB of RAM for the project to load. I am honestly quite interested in what could happen (either something mundane will happen, like my computer restarting, or something crazy can happen) but I don't want to risk it.

Here is me risking it -

Raihan142857 wrote:

I have 4 GB of RAM and 3.6 GB of free disk space. It took Chiroyce 14 GB of RAM for the project to load. I am honestly quite interested in what could happen (either something mundane will happen, like my computer restarting, or something crazy can happen) but I don't want to risk it.

You would've gotten a Blue Screen on Windows or a kernel panic on macOS/Linux because

Chiroyce wrote:

It also had to utilize the SSD for memory, about 3GB of what had to be written to memory, was written to the SSD, and a lot of Scratchers still use HDDs (hard disks), which means their devices would become insanely slow trying to use 3GB of HDD as memory.

Here is why(?) Forkphorus uses so little memory compared to Turbowarp:
Forkphorus is based off of Phosphorus, which was an HTML5 Player for Scratch 2.0 projects. Forkphorus simply added support for Scratch 3.0 projects. Phosphorus was probably designed to not use a lot of RAM, something that the ST probably overlooked when developing Scratch 3.0. Turbowarp, being based off of Scratch 3.0 for more compatibility instead of Forkphorus, still suffers from the high amount of memory that Scratch 3.0 has.

Support. I don't want my PC to die. If someone with an (almost) brand new Macbook with 16GB of RAM and an M1 SoC has issues, my Surface Book with an 8th gen Intel Core chip will probably get bricked.

dhuls wrote:

Phosphorus was probably designed to not use a lot of RAM, something that the ST probably overlooked when developing Scratch 3.0.

So the ST should fix it, right?

Chiroyce wrote:

dhuls wrote:

Phosphorus was probably designed to not use a lot of RAM, something that the ST probably overlooked when developing Scratch 3.0.

So the ST should fix it, right?

I'm not sure if that's possible, since the comparison between Scratch and Forkphorus/Turbowarp isn't fair. Scratch converts Scratch code into Javascript on the fly, whereas Turbowarp compiles first. I'm not an expert in these sorts of things but I think that reduces memory usage by a lot.

Support, because apparently iPhones and iPads are too optimized to have RAM and high-ram devices are way too expensive nowadays (atleast for turkey).

Support, I have 8 GB of RAM (More like 7.9 GB but still) and Chrome just crashed, it straight up crashed.

potatophant wrote:

support, this is actually ridiculous, and scratch's current system is a terrible way of handling assets in memory. it would be better to load and unload assets as they're needed, similar to how unity, unreal, or pretty much any respectable game engine out them. this might take a bit of work, but it really should be done since this kind of thing is pretty much essential for something like this.

This would go a long way in reducing the load of assets on RAM, but—and take this with a grain of salt because I really have no experience with any of these game engines :P—is there actually any way to predict which assets will be required soon, so they can be preloaded? I'm pretty sure the reason Scratch keeps all those assets in memory at all times is so that they can be used immediately, without any delay, which is pretty important for most projects.

Most games use loading screens or otherwise dynamic loading in order to load assets without interrupting gameplay, and they can do that because they know exactly which assets are going to be needed soon… but I can't think of how the Scratch language would detect that itself, which it would need for its own dynamic loading. Depending on the user to explicitly say which assets need to be loaded is obviously too complicated and impractical for most Scratchers, but I can't think of what another solution would be!

bump