-
Notifications
You must be signed in to change notification settings - Fork 176
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
frontend: Small performance improvements #2590
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit surprised we need memo(...)
surrounding a bunch of components. I thought this was only needed if we were doing a lot of complex work in components' bodies, and even those could be abstracted into useCallback + useEffect to avoid this.
Let's look at what is happening on the main branch, without optimizations. This PR is mostly focused on the Sidebar and navigating between pages. The test case is clicking on Pods from Deployments page. I've commented out the Table so it's clearer. What we see here is the first rerender that happens after a click. The trigger is the change of current route and the whole sidebar rerenders. Then there's another identical rerender when sidebar selected item in a slice updates. (Ideally it should derive that from the url but that's a different issue) What user sees is Pods button turns yellow and Deployment button turns back to black but we're rerendering every item. You might think that rerendering the same thing in react is not a big deal and in most cases it is not. But what we see is that single rerender takes 70ms (to maintain 60 fps you need to have less than 16ms per frame) Let's see what code actually runs during this without the react profiler overhead. Here I'm using the Chrome Profiler. On the top is the flame graph that represents CPU work over time and on the bottom is the list of functions that take the most time. 6 out of 10 slowest functions are from mui/emotion styling packages dealing with generating styles in runtime. This can be somewhat improved by getting rid of sx usage everywhere and using separate Style recalculation is taking a big chunk here because certain mui components use functions like So this is not React's fault. Aggresive memoization will help us deal with runtime style generation and heavy mui components. |
Thanks a lot for the explanation. Appreciate that. I am willing to merge once the conflicts are solved. |
Merge conflicts were fixed |
6b64daa
to
0964a3a
Compare
@sniok I have rebased these changes but noticed there's a bug related to my previous concerns: if you add content to the creation dialog (from the create button), then you apply and it fails to apply, or you close and reopen that dialog, it will no longer retain the contents that the user has added. This is a UX problem. So to fix this while keeping your goal of not rendering unless necessary, I added a new commit which only renders the dialog after it's first opened (unless the keepMounted prop is passed, as maybe some plugins do want to pre-render it). |
0964a3a
to
e936975
Compare
Signed-off-by: Joaquim Rocha <[email protected]>
There's a simpler fix for that, we can preserve the state of the EditorDialog but also avoid rendering the Dialog by reusing the I've dropped the initial commit and added a new commit with this fix. |
Signed-off-by: Oleksandr Dubenko <[email protected]>
Signed-off-by: Oleksandr Dubenko <[email protected]>
Signed-off-by: Oleksandr Dubenko <[email protected]>
Signed-off-by: Oleksandr Dubenko <[email protected]>
Signed-off-by: Oleksandr Dubenko <[email protected]>
c4e8cc4
to
ec42137
Compare
This PR adds some useMemo, memo, useCallbacks to avoid unnecessary rerenders. Also hides a create resource popup when it's not open