[bug]: WebUI client-side (JS) does not garbage collect memory until user refreshes the page

[infinity0]

Is there an existing issue for this problem?

• I have searched the existing issues

Operating system

Linux

GPU vendor

AMD (ROCm)

GPU model

No response

GPU VRAM

No response

Version number

v4.2.6post1 + PR #6539

Browser

Firefox 128.0+linuxmint1+virginia

Python dependencies

Using Python 3.12 as per PR #6539 since Python 3.11 has been dropped from Debian Testing.

What happened

1. Run InvokeAI on some server machine and make the WebUI port open to another client machine. All subsequent steps are done on the client machine, it has nothing to do with the server.
2. On the client machine, open a system monitor to check your RAM. Note the starting RAM usage.
3. Go to the InvokeAI Use the Unified Canvas on a large image
4. Keep outpainting and doing bigger edits
5. Watch your RAM go up. Wait a few minutes. Watch your RAM not go back down.
6. Refresh the InvokeAI page. Watch your RAM go back down.
7. Optionally, skip step 6 and watch your browser use more and more RAM until your OS starts swapping and it becomes unresponsive.

What you expected to happen

I should not have to manually refresh the page every few minutes to avoid the InvokeAI web UI hanging my computer.

How to reproduce the problem

See steps above.

Additional context

No response

Discord username

No response

[psychedelicious]

Does clicking Clear Canvas History fix the issue?

[infinity0]

Clear Canvas History doesn't seem to have an immediate effect on memory usage here.

Upon further examination it appears the Web UI does occasionally garbage collect, in that my RAM usage does appear to go down from time to time. However after extended prolonged use (30-60 min, >100 1024x1024 generations) the overall usage still goes past my RAM capacity as per my original report.

[infinity0]

More specifically what I'm doing is:

1. Generate 8 1024x1024 images (e.g. with JuggernautXL) at a time, in Unified Canvas outpaint mode, building on the previous images.
2. When the generation finishes, cycle through all the images so they actually load into the browser and take up RAM.
3. Accept one of the images. RAM will go down a bit, but not always all the way back down to what it was in step (1).
4. Repeated steps 1-3 and watch your overall RAM usage shoot up through the roof.
5. Clear Canvas History doesn't affect RAM usage directly at all. By contrast, refreshing the page does clear out your RAM.

Hopefully you can reproduce with these steps on Firefox ~128.

[infinity0]

The problem does not seem to exist - or exists to a much lesser degree - on Chromium 126, RAM usage is stable even after the above steps. Specifically in (2) is where Firefox RAM usage shoots up the fastest, on Chromium it hardly budges.

[infinity0]

Actually the problem does exist in Chromium, just perhaps a bit slower than Firefox. The main contributor is step (2), cycling through the images. If you cycle through the images, waiting 1-2 seconds between each arrow press, the RAM usage continues to go up, even when cycling past previously-loaded images. Clear Canvas History doesn't help, refreshing the page does help.

[psychedelicious]

The high-level, declarative API used by canvas is holding references when it should be releasing them, preventing the browser from GC'ing. That API doesn't let us manage references effectively - it's too abstract.

Canvas is in the middle of a full rewrite using a lower-level, imperative API. I've put a lot of attention and care into efficiency in the rewrite and I don't see this issue there. Memory allocations are substantially reduced overall.

I don't plan on investigating this specific issue since the affected implementation is on its way out.

[psychedelicious]

Invoke v5 features a full rewrite of the canvas. Please create a new GH issue if the problem still exists in the new canvas UI.