I'm running it on my own server and performance is quite acceptable. Picking the right client is very important, though; Element isn't always the fastest, and I find Cinny's UX to be much better for general chat, which is clearly very much… inspired by Discord. On the other hand, Element is ahead in terms of features and protocol support (like the (live) location sharing feature), but Fluffychat has the superior mobile app in terms of general look and feel IMO. On the desktop, Nheko is incredibly fast, being written in a native language and being optimized for performance and all, but I don't use it because I just can't get used to the design.
When joining huge chat rooms like some of those on the matrix.org homeserver, it can take a bit for the clients to sync up and get going. Performance is getting improved all the time, especially in terms of quickly joining a room. Latency also doesn't help, the protocol requires loads of round trips for the JSON payloads to go back and forth, so if you're not near your homeserver you're going to see some annoying problems.
I recommend giving the platform another quick try using https://app.cinny.in/ which to me feels very Discord-like in terms of snappiness.
Cinny user registration told me my username was already taken, and threw up a never ending captcha[0]. I nevertheless got a "validate your email" in my inbox, although I can't login. Not, like, a great start.
The problem of slow joins isn't the client, it's the protocol. Just join the Synapse admins channel on matrix.org (will take half an hour to load, your client will time out and give you an error but it will load eventually) and the other admins will tell you they're all aware of the problem.
Shocking to see Arathorn deflecting about this. I run a server and just never use federation to avoid the problem.
I’m not deflecting - i’m just trying to figure out which slowness folks are complaining about. Is it really slow joins over federation (which is absolutely a real problem, which is why we’re busy implementing https://github.com/matrix-org/synapse/milestone/6). Or is it Element Android being sluggish when changing rooms? Or is it a slow server being slow to send messages?
My point was that saying “matrix is slow” is unhelpful given it’s completely unclear what aspect is being complained about.
I disagree that the protocol is the problem. There's a combination of frontend/backend issues impacting performance, but servers written in faster languages don't seem to struggle with joining channels all that much.
Synapse being written in Python seems like a much bigger problem to me. This problem only exists in rooms not already available on the server, though; if you register with matrix.org then matrix.org rooms won't suffer nearly as much as running your own server.
Sadly, alternatives like Conduit still aren't fully-featured and they probably won't ever be as focus lies on the Element ecosystem. It's a real shame.
The problem of slow joins isn't the client, it's the protocol. Just join the Synapse admins channel on matrix.org (will take half an hour to load, your client will time out and give you an error but it will load eventually) and the other admins will tell you they're all aware of the problem.
I don't know why Arathorn is further down the thread dismissing this problem.. it's a well-known problem in the community..
They're talking about a specific issue with federation at scale. I run a hybrid conference in Seattle and we use Matrix. I make a successful living out of this, so it seems a stretch to call it useless.
> 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.
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.
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.
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.
