Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

room switch time is slow on a ~10 page roomlist due to forced layouts in _restoreSavedScrollState #14574

Open
ara4n opened this issue Jul 17, 2020 · 14 comments
Labels
A-Performance A-Timeline O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@ara4n
Copy link
Member

ara4n commented Jul 17, 2020

takes ~1.2s to change room on Riot Nightly.

@Half-Shot
Copy link
Member

semi-related #14539

@MacLemon
Copy link
Contributor

It takes 1-2 seconds to update the unnecessary highlight/rollover effects in Element, switching a room takes between 3 seconds (direct chats) and 10 seconds (medium to large rooms) now.

@t3chguy
Copy link
Member

t3chguy commented Jul 17, 2020

@MacLemon your issue sounds like #14539

@turt2live turt2live added this to Inbox in Room List v2 via automation Jul 17, 2020
@turt2live
Copy link
Member

turt2live commented Jul 17, 2020

on the surface this is a duplicate of #14539 however internally it's been noted that there's a particularly slow function in the room switch path.

Edit: which is also listed in the title - I can read, I promise 😅

@turt2live
Copy link
Member

From the performance profile this is a regular issue and nothing to do with the new room list

@turt2live
Copy link
Member

there's two kinds of updates we're doing:

  • A Recalculate Style due to trying to set height on the item list
  • A Layout due to trying to set scrollTop on the parent node

We then repeat the two for a height update a moment later, however this seems better scoped and not actually an issue.

@turt2live
Copy link
Member

and now by doing exactly nothing I've reduced this down from 30ms to 1ms.

@turt2live
Copy link
Member

turns out if we simply add an if statement we can often save 28ms

@turt2live
Copy link
Member

caught a capture of this where a room switch took well over 800ms (!!!!!!!!) with only about 10 rooms shown (not 10 pages, just 10 tiles).

It looks like we're unmounting hundreds of components, then mounting hundreds more, and React is trying its best. Each mount only takes 0.12ms, but multiplied by a few hundred it starts to add up. It also looks like mine got caught by 2 GC's in the middle of switching, 15+ forced layouts, and what Chrome is calling a layout shift.

The scroll state only accounts for ~100ms of this, so will need to investigate how we can possibly speed up the (un)mounting of event tiles.

@turt2live
Copy link
Member

image

for the above comment: tall graphs are bad.

@turt2live
Copy link
Member

The profile hasn't improved but room switching feels faster with matrix-org/matrix-react-sdk#5034 - not sure how much of that is placebo.

@MacLemon
Copy link
Contributor

MacLemon commented Jul 22, 2020

@MacLemon your issue sounds like #14539

That performance is observed when the list is collapsed so it actually fits on my laptop screen. Meaning that it can display 13-ish items in total accumulated over all sections.

@ara4n
Copy link
Member Author

ara4n commented Oct 23, 2020

The room change time is still excruciatingly bad on my account (with ~300 rooms visible in the list)

@turt2live turt2live removed their assignment Oct 23, 2020
@Half-Shot
Copy link
Member

This issue continues to bite me, and it's making me consider using other apps just to get some work done. I can't wait multiple seconds to switch rooms :(

@MadLittleMods MadLittleMods added S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Occasional Affects or can be seen by some users regularly or most users rarely labels Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Performance A-Timeline O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

No branches or pull requests

8 participants