> 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.
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...
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.
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
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.
> 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:
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