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

Rendering performance in Vector feels about 3-5x slower than the vanilla react example. #125

Open
ara4n opened this issue Aug 30, 2015 · 11 comments
Labels
A-Performance O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect

Comments

@ara4n
Copy link
Member

ara4n commented Aug 30, 2015

No description provided.

@ara4n
Copy link
Member Author

ara4n commented Oct 11, 2015

This is really painfully obvious when trying to resize the window (its trivial to max out 8 cores at 100% CPU just by rerendering), or using the app on Mobile Safari, where everything is sluggish as all hell.

@ara4n ara4n added P2 and removed P3 labels Oct 11, 2015
@ara4n ara4n modified the milestone: Ragnarok Nov 29, 2015
@ara4n ara4n removed this from the Ragnarok milestone Apr 13, 2016
@Half-Shot
Copy link
Member

This is presumably no use to anyone anymore?

@turt2live
Copy link
Member

It's slow.

@turt2live turt2live reopened this Mar 18, 2019
@Half-Shot
Copy link
Member

Half-Shot commented Mar 18, 2019

Do we not have a more targeted issue for "It's slow" than a issue about Vector in 2015 based off a old react example? Or put another way, is this issue helpful?

@turt2live
Copy link
Member

tbh @lampholder would be the judge of how helpful an issue is, but in practice Riot is incredibly slow at rendering things (hundreds of milliseconds) which is problematic.

@Half-Shot
Copy link
Member

Fair, I agree with the slow. I just think this isn't a great issue :)

@jryans
Copy link
Collaborator

jryans commented Mar 18, 2019

I also agree this issue isn't great... It's not very actionable as it stands.

It's quite general and the desired outcome is vague, so even if many performance improvements were made, it would be hard to say if this issue could be closed. I think more targeted perf issues that focus on getting some area of code to meet some performance goal would be better way forward.

@ara4n
Copy link
Member Author

ara4n commented Jan 13, 2020

#4997 is related, but i'd suggest keeping this open - it's literally "if you scrub the window around to resize it, it is incredibly sluggish to rerender"

@ara4n
Copy link
Member Author

ara4n commented Jan 13, 2020

i suspect that killing the remaining gemini scrollbars with fire would help a lot.

@ara4n
Copy link
Member Author

ara4n commented Apr 7, 2020

killing the remaining gemini scrollbars with fire did help a lot.

I still think we should profile the rendering properly though, relative to the original react example - my hunch is that there's something about our heavy use of nested flexbox that means that we're working CSS harder than we need to be, and strategically removing flexbox in a few places might speed things up enormously.

@germain-gg
Copy link
Contributor

It seems that horizontal resizing of Element is pretty intense

Screen Shot 2021-05-17 at 15 33 05

Resizing takes about 37ms with a pretty heavy layout operation being performed. This happens when being in an idle room. Anything else significant being dealt with at the same time is going to make the resizing experience even slower

@germain-gg germain-gg added P3 and removed P2 labels May 17, 2021
@amywalkerdev amywalkerdev added S-Minor Impairs non-critical functionality or suitable workarounds exist O-Occasional Affects or can be seen by some users regularly or most users rarely and removed P3 labels Oct 19, 2022
@dosubot dosubot bot added O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround labels Jul 4, 2024
@langleyd langleyd removed S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience labels Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Performance O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect
Projects
None yet
Development

No branches or pull requests

7 participants