GB Studio Stops Responding When Running Project

[MaxBeforeTheOne]

Describe the bug A clear and concise description of what the bug is. After updating to GBS 4.1.1/4.1.0, GBS stops responding whenever I try to run my project.

To Reproduce Steps to reproduce the behavior:

1. Press the run button.

Expected behavior A clear and concise description of what you expected to happen. By the time the compiler gets to "Compiling Events" GBS stops running.

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

• App version [4.1.1]
• App version [4.1.0]

• Additional context Add any other context about the problem here. I've gotten my project to run once in 4.1.0, not sure what the difference was though.

[MaxBeforeTheOne]

So I was able to get through an initial run, but now GBS seems to stop responding for a long time every time I run it. And it also seems to be fully recompiling everything every time I do run it.

[MaxBeforeTheOne]

I managed to get past all of the new errors and whatnot from updating from 4.0.2. But now I'm still stuck with a build time of nearly 6 minutes.

[chrismaltby]

Hi @MaxBeforeTheOne that portion of the build process definitely takes longer in v4.1.0/v4.1.1 as scripts now need to be compiled multiple times to fix some issues that had been seen in previous versions. Thought 6 minutes is definitely excessive.

Short version of this is that previously each custom script you defined would only be compiled once, but if you did something like launch a projectile in a script, then used that script in multiple scenes but those scenes themselves did things that caused the projectiles to be in a different order in memory you could end up with the script launching different projectiles in every scene. This wasn't just projectiles there multiple similar issues like this.

So in 4.1.0+ it's now builds a script (almost) every time it's called on the off-chance that the compiled result would be different to other calls of the same script. That's not to say it can't be optimised again but at the moment it's being written for correctness.

Would you be willing to share your project files, either here, or if you're not comfortable sharing it publicly, you could email to my first name.my last name@gmail.com (replacing in my name :-)) and I might be able to have a look if there's anything specific about your setup that I could add an optimisation to cover

[MaxBeforeTheOne]

Sent it to your email.

[chrismaltby]

Got it thanks, might be a few days before I get a chance to look into this

[chrismaltby]

Just wanted to let you know I've started to look at this, not sure what's going on yet. I'm seeing long build times like you suggest when using the app BUT weirdly it can do the "Compiling Events" step in under 10 seconds if I use the CLI tool instead (which should be running the EXACT same code). Something very strange going on but I'll figure it out 👍

[chrismaltby]

I've learned a little more, in that the reason I get MUCH faster build times using the CLI tool is that I'm using a newer version of NodeJS (v21.7.1) than is packaged with the application (v16.17) which seems to give improved build times. The problem is to get a newer version of Node in the application, I'd need to use a newer version of Electron and I believe the version we're using right now is the last one that supports Win32. Which means there's a big speed boost we could get if we dropped support for Windows 32-bit :-/

[MaxBeforeTheOne]

Dang. Obviously dropping support for stuff isn't great, but if there are already these slowdowns for people with Windows 64-bit, surely it must be worse for those with 32-bit? I also just wanna mention I've seen other people running into the same "GBS has stopped responding" issue as me in the Discord. Regardless though, I hope you can come to some sort of conclusion to get this sorted.

[chrismaltby]

More progress, I've got an updated development build here: https://github.com/chrismaltby/gb-studio/actions/runs/10753340524

Which while it won't run any faster, it runs the build steps in a background process, which means the UI won't freeze during a long build at least.

The next step is to figure out what can be done to reduce the time the project build is taking.

I'd like to try a few things before going down the "drop Windows 32-bit support" route, still a surprisingly large number of users running 32-bit Windows if the Itch.io download analytics are anything to go by.

[chrismaltby]

I've made some progress with optimising build times. Using this development build: https://github.com/chrismaltby/gb-studio/actions/runs/10761388190 With your project now takes me 2m 48s from a cleaned cache and about 32 seconds for every subsequent build. During this time the UI also doesn't freeze once.

I still need to do more to confirm that this version is ok to merge, but if you want to get it a try on your project and confirm everything is working as you expect that would help me out :-) Thanks

[MaxBeforeTheOne]

Not getting any UI freezes, but first two builds kept canceling themselves with all of these errors appearing.

After clearing the build cache, I keep getting errors related to my music tracks. Even I remove one or all of them it'll either just show a similar error message like this, or just cancel the build immediately after "Preparing Music...". Even with bringing over a new build from 4.0.2 that I've continued working on.

[chrismaltby]

Oh weird, looks like some of the changes don't work on Windows then. I'll have to boot up a virtual machine running Windows to see how to fix this issue instead. Sorry about that.

[chrismaltby]

I've managed to set up a full Windows dev environment and reproduced the issue you were seeing. I think this build is the one now, no pauses during the "Compiling Events" step, and no "ENOENT" errors when compiling https://github.com/chrismaltby/gb-studio/actions/runs/10763296990

[MaxBeforeTheOne]

There's no freezing, and the errors are gone. I did two builds after the first big one and they both took 1 minute and 34 seconds exactly, which is still slow, but wayyy it's better than what it was before. Though doing builds in 4.0.2 takes me around 40-50 seconds for comparison.

[chrismaltby]

Thanks for testing this build, I think this is probably about as fast as I can optimise the build process for now without making some more major refactors to see if more things can run in parallel. At least the original issue of the application not responding is fixed and build times are closer to what they used to be.

I've included these changes in 4.1.2 which I've released today.