Not the person you're replying to but following up on an identical past thread: https://news.ycombinator.com/item?id=30996203

> Linux, x86_64. Getting the same behavior across distros and installations.

It is still very much the case. To emphasize, we have for the past couple of years used Matrix routinely on:

  * Multiple client implementations
  * Multiple OSs (Linux/Android/iOS)
  * Multiple accounts and profiles
  * Multiple Linux distros, desktop environments, window managers, X11/Wayland, CPU architectures (x86_64, aarch64)
  * Private and public homeservers

In particular, multiple accounts on the same Linux installation of element-desktop.

The common denominator seems to be that the account with many (thousands) of rooms (almost all of which fully historical/archived with no ongoing activity apart from participants presence) consistently gets Element freeze, hang, be extremely slow.

This makes element-desktop practically unusable for that account. Other accounts in the exact same environment do not have this issue. Signing in to a fresh profile seems to improve this, for a while, until it starts happening again

The same issue does not appear on Element iOS/Android, or with other accounts on the same client.

It gets more annoying by the fact that even under normal operations it's slow enough to start up that it can take some time to tell if this time it'll eventually resolve by waiting or if it needs to be force-killed and restarted. This is also the case on an otherwise idle 8-core Ryzen3 with 64GB of RAM and fast NVMe drive sitting close to its homeserver on a 1GBps link. (The slowness seems to be all or mostly locally in Element - even when in a mostly empty room, it can take a very long time expanding/collapsing/navigating the People/Rooms sidebar. This, too, only for those particular high-room accounts and only on element-desktop)

For a while we believed it could have been the same cause as this issue[0] but alas, 1.11.0 with Electron 19 has not resolved it.

The common factors that consistently exhibits this behavior seems to be Linux, element-desktop, account with large amount of rooms. Been like this for a while now.

[0]: https://github.com/vector-im/element-web/issues/21147

Element Desktop shouldn't freeze, hang or be extremely slow on an account with large numbers of large rooms. My personal account is in around 4000 rooms which span around 500K users, and it's completely usable on Element Desktop on macOS on an average intel macbook from ~4 years ago.

So whatever is going wrong here is presumably a Linux-specific bug on Element Desktop, which I'm unaware of, and haven't heard from any of the other linux Element Desktop users. Have you filed an issue with logs to get it on our radar? HN is not our bug tracker...

There are two issues filed already which I think sounds similar enough, and from the referenced it obviously scales:

https://github.com/vector-im/element-web/issues/20431

https://github.com/vector-im/element-web/issues/20143

I think the reason you don't see log reports here is that a condition for this to be problematic is large number of rooms/DMs. We could audit/edit the logs and submit them manually (and perhaps I'll get around to that). I also suspect high-intensity users are more likely to disable telemetry.

Just putting out a possible explanation why this issue may be more prominent than can be gathered from analytics. You do seem to recognize the common complaints of slowness (the dismissal of which prompted me to follow up in the first place), and there is at least one GitHub issue open by prominent community members since ~6 months.

It's literally impossible to tell whether the two issues you've linked are the same as the one you're complaining about unless you submit logs and your own bug so we can triage to see why your client is slow.

Hey, I'm not expecting you or anyone else to spend time or resources on this. These threads were all prompted as replies to different forms of dismissal of other individuals claiming that element-desktop is slow. I want Element to be great and to be able to honestly vouch for it.

It would be more honest to say something like "element-desktop works great on macOS and keeps improving on all platforms", rather than pretending like anyone with issues is an edge case. Could it be that you, who work closely to the product, are more of an edge case?

We all have our blind spots.

If you have time at some point, maybe spin up an Ubuntu/Fedora/whatever VM, install element-desktop, sign in to your account and try to use that as your desktop driver for two weeks. Should be straight-forward enough on a Mac. It needs to be with your largest account. Consider it a challenge.

That is the problem with defining Linux Desktop support as I have said this many times before. It has been more than 20 years and the same fragmentation and inconsistency issues are still here. It is not early days anymore.

It works fine on macOS as mentioned in that thread, especially with 4000 rooms on both Firefox and Chrome and supporting that is simple with a predictable desktop stack. The Linux Desktop however is eternally plagued with these issues and the support and testing is very expensive.

It is a serious and fundamental problem with multiple alternative of alternatives of system components to test and the problem [0] may still happen deeper in the desktop stack and looking for the root cause is like finding a silver needle in the sky and would require a mixture or part time / full time devs to test or debug literally everything that is in the stack to reproduce or actually find it.

The fact that it works fine on macOS and it hasn't been solved on Linux yet, tell us that defining Linux Desktop support and targeting / supporting 100% of Linux Desktop users is an impossibility. It's a very expensive contraption to support, unlike the users on Windows and macOS.

[0] https://news.ycombinator.com/item?id=30983400

For all is warts, electron does make things like this more consistent across distros end environments, as shown in the reproducibility of this issue.

Probably because the app is a bloated piece of junk

All Electron apps are slower by orders of magnitude than the native ones by definition. Trying any non-Element client might help.

Could you please suggest one native android client?

A sibling comment [1] says it works fine on Mac and Windows, and it's all the same desktop app. It's likely a Linux quirk that hasn't gotten enough attention yet

[1]: https://news.ycombinator.com/item?id=32021303

There are plenty of apps that run smooth on Linux. If there is a bug, then it almost definitely isn't due to Linux itself. Maybe they could just admit their development efforts aren't actually focused on optimizing for open source.

> this is like saying “i tried the web, and it’s extremely slow”

Uuuuuh ok...? WhatsApp isn't slow.

The matrix protocol is an open protocol where anyone can build on. You using the matrix protocol is the you using http. So your slowness equates to the server you are communicating with. Note: Yes, the protocol has issues when you are joining larger rooms. But for WhatsApp scale (max 256 users in a group) matrix works pretty well.

Uhhhh ok? Email is fast.

How about slow compared to Discord?

But this still doesn't answer the question - did you register on the default server that everyone uses (matrix.org)? And in that case, you've given the exact worse case scenario: The heaviest server, being used by everyone else, with massive rooms, and constantly fighting off spam.

Personally, I find that the Matrix.org server is much better for large rooms. Most of the content is already cached on the server by all the other accounts on there, so joining large rooms takes seconds instead of minutes. Modern sync (v3 already, I think?) also helps a huge amount but it needs client and server support.

I've tried to join the main matrix chat room (#matrix:matrix.org) but my poor homeserver just couldn't handle it.

Modern sync (sliding sync, v3 sync) only helps with non-encrypted rooms. For encrypted rooms, it degrades to essentially the old sync v2 performance.

That's true, but most rooms where this is a problem (the huge ones) aren't encrypted. There's no way you're going to cross-verify everyone in a room with 4000 users in it so encryption in such rooms is essentially useless.

Not everyone uses matrix.org. I've run my own server on a $15/mo DO droplet for ages and my whole polycule and friend group use it heavily as well. It's incredibly easy to deploy and maintain for anyone who knows even a little bit about sysadmin.

same. i have yet to bother switching from sqlite to postgres and it's ... fine. it's fine.