element-web runs into issues on multiple different device types due to excessive memory usage

[ell1e]

Steps to reproduce

1. Use either a device with little memory (I used a 3GB RAM ARM64 device, the PinePhone Allwinner 3GB variant) or a more regular device with more memory where the browser is configured to unload tabs that go completely out of control on memory (I used a Skylake x64 laptop with 16GB RAM for this one)
2. Make sure earlyoom or some similar service is active so you won't hang your entire device
3. element-web tab keeps crashing because it uses too much memory and gets shot down by earlyoom (little memory device scenario) or keeps getting unloaded by the browser for being so excessive in use (regular device scenario)

Since telegram-desktop works perfectly fine and Discord web even on the small device crashes way more rarely even though I'm in probably 2x-5x the chat rooms on Discord to Element, this doesn't look reasonable in comparison to competitors.

Outcome

What did you expect?

Works

What happened instead?

Constantly runs into notable issues due to runaway excessive memory use

Operating system

postmarketOS (based on Alpine Linux) for the small device, Fedora Linux for regular device

Browser information

Firefox ESR 91.13.0esr for little memory device, Firefox 111.0b8 with browser.tab.unloadOnLowMemory set to true on regular device

URL for webapp

app.element.io

Application version

crashes too early to reasonably check on little memory device, 1.11.24 on regular device

Homeserver

matrix.org

Will you send logs?

No

[robintown]

This will potentially be solved by Sliding Sync.

[t3chguy]

Non-desktop environment is experimental as per support policy

[ell1e]

I just terminated element-desktop after using short of 700MB. Unless the code base difference to element-web is the reason for the huge discrepancy, I'd suggest this is also affecting desktops since that's a pretty sizeable amount to gobble up on a regular lower spec computer. And maybe it's not that uncommon either.

Edit: after restarting it to see how much of this was leaks over time, it actually used 900MB right away. Wow. Eventually it went down to below 500MB, but that peak is pretty extreme for a chat app.

[DeezyTheFox]

Edit: after restarting it to see how much of this was leaks over time, it actually used 900MB right away. Wow. Eventually it went down to below 500MB, but that peak is pretty extreme for a chat app.

I'll just put it here

[mpeter50]

On desktop I only use Element-Web in browser (Firefox), and according to the about:processes page it easily consumes 1-2 GB of RAM, sometimes 3. Not right after loading the client, but a few hours or a day later. This is particularly bad when I have several tabs of the Element client open, and I do that often so that I have different rooms open for different chats where I dont want to forget that I'm waiting for a response, but I don't want to turn on receiving notifications either.

As an example, this Element client was opened approximately 6 hours ago:

The screenshot is from the about:processes built-in page of Firefox.

Devs: if I can help in any way, even with performance profiles or other involved things, I'm happy to help!

[JeanPaulLucien]

Edit: after restarting it to see how much of this was leaks over time, it actually used 900MB right away. Wow. Eventually it went down to below 500MB, but that peak is pretty extreme for a chat app.

I'll just put it here

Oh. It was here. But they did not trust me in December 2022.

[JeanPaulLucien]

Devs: if I can help in any way, even with performance profiles or other involved things, I'm happy to help!

Yeah, check my issues. But you will not make a Profile if you have 8 GB ram or less.

[paboum]

Instead of trying to retroactively catch memory leaks, it might be more prudent to guarantee that reasonable practices are followed in the code.

https://www.electronjs.org/docs/latest/tutorial/performance presents a recommendations checklist to follow. Perhaps one of the devs could prepare a report on how well are they followed, or even write down the action items? Then, the users won't need to facilitate bug tracking and could observe the progress instead.

[ell1e]

On my laptop which has 16GB RAM, the element web tab now regularly gets nuked by Firefox (unloaded) due to the memory usage since I enabled that option, while no other website or web app has that problem. The only difference to the little memory device scenario is that it's not an uncontrolled crash, but the result is kind of the same in that notifications and reachability just don't really work this way and it's a nuisance.

[ell1e]

Sadly, with recent updates this seems to have gotten even worse 😢 with a 3GB constraint often it will out of memory crash on initial load before I can even send a single message, while it used to at least work for some minutes. And even on my normal specs laptop (16gb ram) the tab crashes every hour or so. It's quite sad

[mpeter50]

It is indded sad, but I think there are more appropriate words for it.

A webapp should not use more than 1 GB of RAM, and even that is too many.

But to also be helpful: I have a(n untested) suspicion that high memory usage is related to being joined to a lot of rooms (a few dozen). You may try leaving most of the public ones that you dont regularly use, and see if it improves. Go through the People and the Rooms setion on the sidebar of the "Home" virtual space, but also any other space you have because rooms from those are not shown in the former list.

[ell1e]

I appreciate your remark, although my commentary of it is more aimed at the devs: just in case anyone would ever more officially suggest that as a serious workaround, IMHO joining less rooms would not be an acceptable solution even if it happened to help. I'm in about 10x as many rooms in discord and it runs fine on the same device (well, it lags horribly, but it doesn't OOM crash after barely a minute). Nevertheless, it seems to maybe be an interesting pointer as to where the problem might be.

[t3chguy]

The solution here will be sliding sync, you can try it today in labs if you run https://github.com/matrix-org/sliding-sync against your server. With it your client doesn't need to keep every single joined room loaded.

[paboum]

With it your client doesn't need to keep every single joined room loaded.

@t3chguy: I fail to understand your logic here. If, even without sliding-sync, I can close the tab and then reopen it later, so the client collects all the data it needs from the local storage and the homeserver, how come it needs to store all that in RAM before I close the tab?

Perhaps some kind of garbage collector would help, eh? Let's say the user decides to only allocate 1 GB of memory for client cache. The collector would then periodically check if the limit is not exceeded and free up decrypted messages, downloaded media and other stuff that sticks out and then free it, in the longest-time-not-seen order. Just look how tabs are implemented in modern browsers - I can easily have 100 tabs open and keep my firefox somewhere under 1 GB of actual RAM usage (I just don't display all of them every time I open the browser).

Or, even better, allow users to decide - e.g. this is a large room which I read seldomly, let's unload it from my memory and only load it when I explicitly want it. Still need a way of notifications though so it's up to you how much of this could be done. This, keeping the browser tabs analogy, could be similar to browser task manager - displaying memory consumption of each tab and allowing to "unload tab and kill process". I guess a similar thing could be tricky since javascript is a single threaded language, but surely you can take the idea from here.

[t3chguy]

how come it needs to store all that in RAM before I close the tab?

Just how the current implementation works, you're right that it could be better by better utilising data stores in the browser, as Hydrogen does. But sliding sync further improves it by making all syncs only include the data the client needs to know at that time, lowering amount of bandwidth & latency needed, as well as intrinsically lowering the amount of data being held by the client, be it in RAM or not.