Frequent long hangs in large rooms on Gitter

[jgonggrijp]

Steps to reproduce

1. Visit app.gitter.im.
2. Sign in.
3. Join gitter/developers or another large chatroom.
4. Wait for the animation to complete that makes a collage of tiny thumbnails of the profile pictures of all the users in the room (this is pointless and annoying, but not the topic of this issue ticket).
5. Interact with the Element interface while inside the room, such as typing a message, opening or closing threads, hovering over buttons, etcetera.
6. Soon enough, you will notice that Element goes intermittently unresponsive. If you type a message, the characters you type take very long to appear inside the message input field. If you hover a button, neither the button nor the cursor change appearance, unless you wait it out. Likewise for the effect that should follow when you click a button.

Outcome

What did you expect?

Whenever I interact with the interface, I expect at least an indication that my action will eventually have an effect within 200 milliseconds or so. Ideally, not only an indication but the effect itself should come instantaneously (i.e., within 50 ms).

What happened instead?

During unresponsive periods, it can take up to 30 seconds before I get any confirmation at all that something might happen. When typing inside the message box, it can take so long before the first character appears, with additional delays before subsequent characters appear. Likewise for hovering and clicking buttons. Unresponsive periods tend to follow back to back, with the intervals between the unresponsive periods becoming shorter over time. After several minutes, Element is pretty much unusable. Safari also displays a message that the site is drawing a lot of energy and will sometimes reload the page for this reason.

The wholesale unresponsiveness made me suspect that something was clogging the CPU, so I let Safari's profiler run for a while. I found periods of 10+ seconds where CPU usage was around the 100% mark. Inspecting one such period, I found that more than half of the time was spent inside a function named getId, which is defined inside js-sdk/src/models/event.ts. It is indirectly called by methods inside MessagePanel.tsx and TimelinePanel.tsx. Unfortunately, the sourcemap is broken, so I could not analyze the call stack in more detail.

Screenshot of the profiler in "reverse" mode (innermost function call on top):

Screenshot of the profiler in "normal" mode (outermost function call on top), showing only one out of three call stacks that are getId-heavy:

Operating system

macOS

Browser information

Safari 15.6.1 (15613.3.9.1.16, 15613)

URL for webapp

app.gitter.im

Application version

Gitter version: 1.11.23, Olm version: 3.2.12

Homeserver

gitter.im

Will you send logs?

Yes

[t3chguy]

getId is a red herring here, the actual issue is shouldShowEvent - duplicate of #24480