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-Swap Performance Analysis #5920

Open
lukebarnard1 opened this issue Jan 4, 2018 · 1 comment
Open

Room-Swap Performance Analysis #5920

lukebarnard1 opened this issue Jan 4, 2018 · 1 comment
Labels
A-Performance T-Task Tasks for the team like planning

Comments

@lukebarnard1
Copy link
Contributor

lukebarnard1 commented Jan 4, 2018

I feel like it'd be fun to put an perf analysis of swapping rooms in a GH issue so here it is. I'll update this comment as I find more interesting things. The chosen benchmark will be swapping between rooms, specifically swapping from #riot-dev:matrix.orgto #riot:matrix.org (having viewed those rooms previously, paginating events in as such).

Observations; it takes about:

  • 700ms in total.
  • 20% of time to mount the middle panel, which mostly consists of mounting events. We already optimise for this by only mounting events that are at most on screen height's worth of distance away from the viewport. Events with read receipts in them take longer - it seems we mount RRs even if they're hidden behind the "+n". We should really only mount the ones that are visible by default.
  • 10% to mount the member list. Nothing remarkable here, it takes a fair amount of time to unmount a bunch of member tiles and then mount the new ones.
  • 6.5% to do forced re-layouts caused by:
    • Gemini mounting or
    • seemingly updating the contents of elements, such as when linkifying or
    • unmounting of elements (after which the re-layouts seem to occur).
  • 5% to unmount the previous RoomView. IIRC, the RoomView needs to be remounted otherwise it'd need reimplementing. This could be because it's children (ScrollPanel) don't function unless the slate is totally wiped clean between rooms. Bearing in mind, most of this will be unmounting events.
  • 4% to mount and unmount the composer, something we might be able to avoid entirely.
  • 54.5% is probably "React" and of course the overheads of the react-perf itself.

Possible Optimisations

Reimplement RoomView to not mount on room-switch

This would remedy:

  • mounting Gemini unnecessarily (and therefore in theory reduce layout reflows),
  • the small amount of self-time taken by RoomView, TimelinePanel, MessagePanel and ScrollPanel to mount AND unmount.
Limit Read Receipts before mounting them

This would remedy:

  • unnecessarily mounting Read Receipts that are hidden initially.
@lukebarnard1 lukebarnard1 self-assigned this Jan 4, 2018
@lukebarnard1 lukebarnard1 changed the title RoomList Performance Analysis Room-Swap Performance Analysis Jan 4, 2018
@lampholder lampholder added T-Task Tasks for the team like planning A-Performance labels Jan 8, 2018
@ara4n
Copy link
Member

ara4n commented Mar 13, 2018

Here's a very similar bug I filed 1000 bugs earlier :) #4997

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Performance T-Task Tasks for the team like planning
Projects
None yet
Development

No branches or pull requests

3 participants