TurboWarp uses so much RAM when playing heavy projects

[Alestore]

While I am running my TurboWarp game (331 MB) I notice that the RAM is occupied between 4 and 6 GB. I don't know how such a thing is possible, I read a previous post here on packager issues and it was said that RAM usage is not under anyone's control. If there is any way to fix or optimize this, write here please.

[GarboMuffin]

Has it always been this bad or is this a recent regression?

[Alestore]

Always been this bad

[GarboMuffin]

Which version of the packager are you using? Starting a few days ago the online version received some optimizations to bitmap costumes; does your project use many of those?

[Alestore]

I'm using the online version (I think is always updated so I use that version). My project use lots of SVG files so I think that's the problem.

[GarboMuffin]

Next update will fix a memory leak in the plain HTML environment if you use that

I'm also working on something else that should save memory by removing the original data for costumes and sounds once they're no longer needed (the packager doesn't have to worry about the editor after all)

Consider posting your project publicly here or emailing it to contact@turbowarp.org and I can take a deeper look into your specific project

[Alestore]

Ok thanks. Currently I'm using Electron at 64-Bit for Windows and eventually Linux. I'll send you an email with the project today.

[GarboMuffin]

Previously mentioned upcoming optimizations by removing the original data for costumes and sounds will save you around 500MB in this project.

However, the biggest problem for you is the amount of sounds: you have almost 5GB of decoded audio. Here's a table of roughly how much audio data each sprite of your project has:

(table redacted here; see email)

You can generate this table yourself by running

vm.runtime.targets.map(target => [target.getName(), Object.values(target.sprite.soundBank.soundPlayers).map(i => i.buffer.length * i.buffer.numberOfChannels).reduce((a, i) => a + i, 0)]).sort((a, b) => b[1] - a[1]).map(i => `${i[1]}\t${i[0]}`).join('\n')

in the JavaScript console.

The situation is especially worse because many of your sounds are stereo when they maybe don't need to be (stereo sounds use double the memory of mono sounds). Editing a sound in Scratch's sound editor will convert it to mono, so something like reversing each of your large sounds twice, especially the ones in the stage, should help a lot by ensuring they're in mono hopefully without impacting their audio quality too much (make backups ahead of time, of course).

I have noticed some issues in Scratch's audio editor however: It doesn't tell you when a sound is stereo and it refuses to let you edit sounds that are "too large to save". I will be looking into fixing both of these issues in an upcoming TurboWarp update.

[Alestore]

I tried to modify the sounds, especially those of the Stage and the heavier ones seen in the table you sent me by doing a double reverse to turn them into mono audio. The larger files, which are longer than 3:40 or 4 minutes, did not let me edit them but for the others I did everything. While I was doing it I saw that the RAM was gradually recovered, I think I have gained at least 2GB of RAM.

[GarboMuffin]

Even better than converting sounds to mono is to remove sounds that you don't actually use, of course

[Alestore]

I was thinking, isn't there a way to make the program that comes out of the packager (in my case 64-bit Windows Electron) read the audio files directly to the disk instead of putting them in RAM? It really takes up too much space and isn't even that optimizable. If this is not possible, couldn't I just convert the audio files (especially the heavier ones) to 128kb .mp3 files?

Also, I noticed that when I use the TurboWarp editor the RAM is taken yes, but the project runs well without frame drops. When I run the packager instead, the HTML only weighs about 3 MB (which is strange for a 370 MB game) and when I open it it gives me an error. For the 64-bit Electron version of Windows the game works, but I have constant slowdowns that make it impossible to play. Edit: I changed the Project ID and seems like to work for the frame drops.

[GarboMuffin]

read the audio files directly to the disk instead of putting them in RAM

I wish it were that simple

128kb .mp3 files?

To be clear, the problem is the decoded audio data which is probably primarily influenced by sample rate and length. If you're okay with your sounds sounding worse, you could try manually downsampling them.

I would suggest waiting before you go that far. Once I finish some sound editor updates (maybe ~Tuesday?), you'll be able to convert some of the larger stereo sounds to mono.

Edit: I changed the Project ID and seems like to work for the frame drops.

I assume by this you mean "I changed the project ID and the frame drops went away"? That would probably indicate that your original project ID had some unexpected cloud variable values that your project isn't handling properly.

A few comments ago I mentioned some upcoming optimizations that will save you 500MB. You can now enable this in Advanced options > "Use "packaged runtime" mode (experimental)". Eventually the option will be removed and this will be the default. If I recall you have some crazy custom JS going on in your project, so consider testing if your custom JS still works in this mode.

[Alestore]

Ok thanks I'll try it and I'll let you know. I will wait for the sound editor update.

[GarboMuffin]

https://staging.turbowarp.org/editor will let you edit sounds regardless of the size (among other sound editor updates), although, like in Scratch, they may be downsampled and sound worse

[Alestore]

thank you I'll do some backups and I'll try this evening. Do you think this will actually work for gaining some RAM? for now, with the newest packaged runtime option from the packager, the game takes about 4,5 GB of RAM in total. I'll modify every single audio file in the project this evening and I'll let you know here. Thank you for your time!

[Alestore]

Is this normal? When I edit audio files from stereo to change them to mono they take up more space instead of taking less (as it says).

Original sound:

When edited with double reverse:

[GarboMuffin]

Raw asset size will be larger (but it should compress pretty well in sb3/zip) but decoded size will be smaller. Yes, it is strange. Just ignore that warning and see if the project ends up using less memory in the packager.

[GarboMuffin]

Scratch's audio editor is only capable of generating uncompressed WAV files. You could use an external audio editor to convert your stereo mp3 files to mono mp3 files to keep the raw file size low and to have more control over the sample rate.

[Alestore]

Raw asset size will be larger (but it should compress pretty well in sb3/zip) but decoded size will be smaller. Yes, it is strange. Just ignore that warning and see if the project ends up using less memory in the packager.

Yes it worked. The packaged file in Electron now use only 3 GB of RAM instead of 5. I gained 500 MB by the packaged compiled option and the rest by editing audio files. Thanks a lot!

[Alestore]

Regarding the HTML export I still have this problem.