[v7] Nested rows performance issues

[vasilii-kovalev]

Describe the bug

Prerequisites:

1. Amount of records: up to 500-600
2. Number of columns: 1 + up to 31 (amount of days in a month), potentially may be a bit more
3. useExpand hook is used (provided with the library)
4. Nesting depth: up to 4

When clicking on an expandable row (a top-level or a nested one), there is a noticeable delay before the status changes, even with 100 records. It becomes worse as the amount of the records grows. According to the profiling results, expanding a row (200 records) takes ~2 seconds, 600ms of which is rendering. I assume that the rest could be related to useTable/useExpand hooks inner logic.

Some profiling screenshots:

And every single cell is rendered.

There is also a related problem: often expanding/collapsing doesn't work when DevTools is opened (in Google Chrome), so it is difficult to profile the table's work.

Your minimal, reproducible example

https://codesandbox.io/s/react-table-performance-issue-u3ob82?file=/src/App.js

Steps to reproduce

1. Wait for the application to be fully rendered
2. Click on any record with 👉 emoji

Expected behavior

As a user, I expected a row is expanded/collapsed instantly.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Windows 10 64-bit
• Browser: Google Chrome 100.0.4896.127

react-table version

7.7.0

TypeScript version

No response

Additional context

There are 2 files with the stubs in the sandbox - stubs and stubs-simplified. In the last one I removed all 0 values from durationByDates objects, hoping that it will reduce the problem a bit, but it didn't help.

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

[tannerlinsley]

Well aware of the performance problems here, unfortunately. This issue is one that I ended up transferring to v8 due to the big architectural changes that were needed to improve it. As far as v7 goes, I'm not going to be tackling the issue there. If you'd like to try out v8 while it's still in beta, I'd love to keep working on the perf expectations there.

[tannerlinsley]

Also worth pointing out here that rerendering/painting is also a pain here. The multipliers are actually really high when you have this many columns, and even just rerendering that many components that have any amount of complexity can be a strain on react itself. While I realize this isn't all of the time spent rendering, it's worth mentioning that the ability to memoize/optimize render performance in v8 is also something that is feasible and easy now (it is not v7 😢 )

[vasilii-kovalev]

@tannerlinsley, thanks for the answers. I have several questions regarding that:

1. When a stable version of v.8 is expected?
2. Will the performance improvements in v.8 be out-of-the-box, like inner optimizations, or it will be necessary to add some code manually on the user's (developer's) side? If the last option, will any examples be provided for that?
3. What can be done, in your opinion, to mitigate the problems in v.7? I'm not sure if memoization of the rows will help in this case...