Lots of join parts lead to bad room performance

[freaktechnik]

Description

Rooms with primarily joins and parts and few actual messages seem to get extremely slow. So slow even, that Firefox warns about the site not responding sometimes.

Steps to reproduce

• Go to room with lots of joins/parts
• Wait for messages like "Ndtm left and rejoined, rapt0r (IRC) and 342 others joined and left, ePirat (IRC) and 14 others joined, TheSchaf (IRC) and 4 others joined and left 2 times" to be generated

I don't have an example of a public room with messages like that, but I'm sure there's some room in the federation with a similar issue.

I am sure it's related to joins/parts since the performance of the particular room has been getting worse the more there are. It feels like there is an O(n^2) implementation here of something that could probably be done in O(n) but that's just a guess without actually looking at all.

I'll happily test this more (like testing it on staging), provide specific details and possibly even contribute a patch for this.

Log: not sent

Version information

• Platform: web
• Browser: Firefox Nightly
• OS: elementaryOS
• URL: riot.im/app

[lampholder]

I think this is because riot tries to render a page full of events, but joins/parts get compressed at render time (by which I mean physically compressed on the screen) so riot has to keep pulling in more and more room events to fill up the whole screen.

[dcermak]

This issue is still present in the current Element version and it got exponentially worse in rooms that were bridged to freenode and moved to libera.chat, as there is a huge number of join/leave events. If you have the setting "hide join/leave events" enabled, then you literally cannot do anything in such a room as Element will just hang even on a very beefy machine.

The Element Android App and other clients like NeoChat don't appear to be affected by this.

[decathorpe]

Yeah, with users leaving freenode for libera.chat and / or matrix directly, this is now very very bad in rooms like #fedora-devel:matrix.org, where opening it hangs my browser for minutes trying to fill the chat window with messages, consuming almost 2 entire CPU cores during that time, rendering those rooms (and the entire browser) completely unusable.

Browser: firefox 88.0.1 with WebRender enabled
OS: Fedora 34 Worksatation / GNOME on X.org
Hardware: Ryzen 7 5800X CPU with 32 GB of very fast RAM, so that should not be an issue

[robintown]

@dcermak @decathorpe I am trying to fix this in matrix-org/matrix-react-sdk#6143, however I have not been able to quite reproduce the claims of ~1 minute hangs that you are reporting. Could you please try the build at https://deploy-preview-6143--matrix-react-sdk.netlify.app/ and see whether it has solved your issue? If not, please use your browser's devtools to do a performance recording of such a hang happening, and export that recording and upload it here.

[decathorpe]

Looks like it only happens if there are a lot of join / part messages from the IRC side of a bridge but very few actual messages. Then if you toggle the option to hide the join / part events, performance goes downhill with element fetching loads of messages to fill the window, but hiding most of them, as far as I can tell.

But the #fedora-devel:matrix.org room is also no longer affected, since there's now actual chat activity and fewer join/leave things happening, so I don't have an example room to test this with any longer :(

[freaktechnik]

When I had initially reported this I recall seeing the aggregation part of the membership messages being really slow (since it would get updated for each event separately or something) thus my vague statements in the original report. I think that'd be the code now at https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/components/views/elements/MemberEventListSummary.tsx . However I haven't seen a big IRC netsplit type of event to reproduce this since.

[robintown]

@decathorpe But the #fedora-devel:matrix.org room is also no longer affected, since there's now actual chat activity and fewer join/leave things happening, so I don't have an example room to test this with any longer :(

If you scroll back to the start of Thursday last week in that room there should be plenty of joins/leaves to test this against, they don't need to be current. I just really want to have feedback from someone who was experiencing hangs, since that's my best lead in solving this issue for good.