Hacker News Reader

Comment by t6jvcereio | Hacker News Reader

Incidentally I tried matrix for the first time on the basis of someone recommending it here in HN, and it's extremely slow

View on HN

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.

[0] https://imgur.com/a/zYBZWoW

https://github.com/cinnyapp/cinny/issues/664 Thanks for the bug report.

I'm not sure the problem was the client (element for Android). Asking around it seems people on the chatrooms kind of agreed the issue was matrix.org

Regardless, if you believe the issue is the client, which would you recommend is the lightest/fastest client?

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.

Not sure why I keep getting flagged

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.

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.

https://news.ycombinator.com/item?id=32020929

I don't know why Arathorn is further down the thread dismissing this problem.. it's a well-known problem in the community..

https://github.com/matrix-org/synapse/issues/1211 there's the seven year old bug

Thank you for this, I was beginning to think I'm the crazy one.

Ok, so matrix is useless then, is that it?

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.

E-mail has much bigger scale and is fast

A single email messages often takes minutes to receive. Conversations are usually highly asynchronous. I wouldn't call it fast, exactly.

this is like saying “i tried the web, and it’s extremely slow”. what server were you using? and which client on which platform?

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.

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

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

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.

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?

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.

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

I found the same, as soon as I join any larger rooms it starts to struggle.

The clients feel sluggish as well, just in terms of moving around the UI.

Reply on news.ycombinator.com