Large amount of membership change events causes lag/cpu spike

[alvinhochun]

Description

If there is a large amount of membership change events in a room, it causes the Element web client to go crazy, dragging the performance of the browser and the whole system down, and have a hard time showing any logs before that.

Steps to reproduce

• Find a room with log enabled and with a lot of membership change events in the history???
• Scroll up

Describe how what happens differs from what you expected.

Logs being sent: yes/no

Room in Element web (https://webchat.kde.org/#/room/#krita:kde.org):

Same room viewed on Element Android:

Version information

• Platform: web

For the web app:

• Browser: Firefox 90b7
• OS: Windows
• URL: webchat.kde.org

[robintown]

@alvinhochun I have been landing fixes for this exact issue on the develop branch, so I highly encourage you to try them out at https://develop.element.io and see whether they have resolved the issue from your end. If you still experience significant lag, please use the performance tab of your browser's devtools to take a recording of such a CPU spike happening, then export the recording and upload it here, so that we can investigate the cause.

[alvinhochun]

Hi @robintown, thanks for letting me know about that fix and sorry for not searching for it beforehand. However, I just tried it on develop.element.io and it does still lag significantly and couldn't load the past log (I stopped it by switching to another room after about 30 seconds of wait). I've made a profile of that in Firefox:

develop_element_io0-profile.json.txt

[robintown]

@alvinhochun Thanks for the recording! The issue turned out to be something pretty specific, and I've submitted a fix which you can try out here: https://deploy-preview-6205--matrix-react-sdk.netlify.app/

[alvinhochun]

@robintown Thanks for the quick update! I've tested it and it has greatly improved the performance when loading the past log of that room. Now it does not hog the CPU and doesn't slow down Firefox like before.

Though I should note that it still took about 20 seconds to get past that part (on the first try, when I profiled it on the second try it seems to have took only 10 seconds). It seems to mostly be idling or waiting for network requests, so probably nothing of interest, but I'll also upload the profile here:

6205_profile.json.txt