DocSidebar performance issues: useless and unoptimized re-renders

[75ta]

🐛 Bug Report

The DocSidebar component should be re-rendered if its content is changed. But now the sidebar is re-rendered each time when the content of the page is scrolled. As a result, the system requires more and more memory, performance is reduced significantly. It becomes difficult to work with documentation, the pages slow down in performance, the interface responses with delay.

We've identified that the re-rendering of the DocSidebar component happens because of the useScrollPosition hook is called. When the hook is disabled, the problem is not reproduced, and no mistakes in the sidebar behavior detected.

When inspecting the problem, we recommend using React Developer Tools on the Profiler tab.

Have you read the Contributing Guidelines on issues?

Yes

To Reproduce

You can find the problem in the following repository: https://github.com/Labirintami/doc/tree/suite_dev_perfomance.

1. Step 1: To launch the project, follow the instructions: README.md .
2. Step 2: Expand the items of the sidebar until the scroll appears. At that, do not scroll the main content outside the sidebar.
3. Step 3: Be sure, that the sidebar is working correctly, doesn't slow down.
4. Step 4: To detect the problem more quickly, scroll up/down the main content several times.
5. Step 5: Scroll Sidebar. Be sure the sidebar freezes while scrolling.

Take a look at this video

Expected behavior

Re-rendering of DocSidebar must be performed when the page is loaded.
Re-rendering of DocSidebar must not be performed when scrolling the page.
Sidebar should work smoothly, without delays.

Actual Behavior

The re-rendering of DocSidebar happens when we scroll the page. The sidebar stops working smoothly and starts to freeze. Eventually, the consumption of the operative memory allocated by JavaScript is growing constantly.

The results on the Performance panel (10sec):

Your Environment

• Public source code: https://github.com/Labirintami/doc/tree/suite_dev_perfomance
• Public site url: n/a
• Docusaurus version used: 2.0.0-alpha.72
• React version used: 17.0.2
• Environment name and version: Chrome Version 89.0.4389.114 (Official Build) (64-bit), Node.js 14.15.0
• Operating system and version (desktop or mobile): desktop Windows 10

[slorber]

Thanks.

I believe this has been fixed in #4473

We'll release the next version soon.

In the meantime, you can try to use the @canary version and let me know if this fixes the problem for you.

In general, I think our sidebars is not very optimized, even if it re-renders uselessly we should try to make this re-render faster. Larger sites with large sidebars might also have non-optimal performances when navigating from one doc to another.

Let's keep this issue open even if the scroll problem is fixed.

[75ta]

Hello, Sébastien (@slorber)!

Thanks for the quick response!

We've checked the version of @canary.

As we can see from the Profiler tab in React dev tool, DocSidebar is still re-rendered on each scroll of the page.

However, the problem with re-rendering of the Navbar component is fixed, thank you!

Our documentation is quite large and often it starts to consume 500 Mb of memory or more after a minute of work.

[75ta]

I have been working with documentation for about 15 minutes, making changes to some pages and opening them via Sidebar.

The tab started to consume 794 Mb (Chrome on Macbook Pro 2016). My colleagues have the same problems in Chrome on Windows.

If you want to test our documentation, run it in the following branch: https://github.com/Labirintami/doc/tree/suite_doc_dev

[slorber]

You can try again with the latest canary, that should be a bit better, let me know.

Will look at how to improve perfs more very soon so let's keep the issue open

[75ta]

Thank you so much for the update! Yes, it's gotten better. DocSidebar no longer seems to redraw when scrolling the page.

Also, for the test, I worked with the documentation for about 20 minutes. I was opening different sections of the documentation through the Sidebar.

It now uses 466 MB of memory. And even if you do nothing, the memory is not cleared.

[slorber]

Hi,

I'm trying to inspect that problem on our site but I didn't see such a high memory usage.

Tried to refactor and optimize a bit more but I suspect it won't change much for you: #4617

To be sure we are profiling the same site, can you please deploy the site you have problems on somewhere (like a Netlify URL or something), so that we can profile the exact same site?

Can you show exactly what you are doing on this site to have such high memory usage?

How does it compare to another SPA that you use for the same amount of time?

This is not something I'm used to profile so I don't know what the expectations are. Maybe it is normal that the memory is not garbage collected if your system does not need it?

[75ta]

Hi, Sébastien!

We've deployed the documentation:
https://docs.dhtmlx.com/suita/
https://github.com/DHTMLX/docs-suite/tree/7.1

And I don't see the same high memory consumption as on localhost.

The sidebar starts to slow down at 60-70 Mb memory consumption.

All you need to do to get this is to open pages 3,4,5 nesting levels and click on them.

The test lasted a little over 7 minutes, the memory consumption sometimes went up to 120-130 Mb.

https://www.youtube.com/watch?v=HQQ348Dj0aI

[slorber]

The memory consumption in dev can be due to the webpack dev server, in-memory caching or something. Not sure I can do anything about it easily.

We are migrating to Webpack5 so it may improve soon: #4089

I'm going to close because I think if the memory of the prod website remains acceptable, and in dev you can refresh the page when needed as a workaround.

Let me know if after the webpack 5 update you still see problems or things get worst for some reason.