Spike(virtualized table): Determine baseline performance expectations

[evwilkin]

Related to #4322

The ask for this issue is to explore similar solutions to the virtualized table extension and determine what baseline performance requirements the virtualized table should meet. Ideally this would include something along the lines of "for a table with 1000 rows and 10 actions per row, the table is expected to render in x seconds and have a response time to user interaction of x".

This can guide the efforts to improve performance and give a standard to maintain with this component.

[redallen]

Intro

It's difficult to give such measurements since browsers and hardware vary greatly. During testing, my own browser extensions played a role in benchmarks. How rendering is measured can also vary (do we count the time it takes to load scripts? do we count the time it takes to transpile the example on the docs site when consumers likely won't do that? do we use a tool like react-dev-tools to estimate how long a component takes to render without accounting for real-world issues like scroll debouncing?).

Testing

Initial load

Testing our docs site

On my machine on a production docs build it takes 1.452s from page load until the table is fully rendered:

For comparison button takes 754ms:

These aren't fair product benchmarks since the docs site asynchronously loads these examples and then uses acorn to transpile it (so the length of the example matters). It's a decent estimate, though.

Testing a simple webpack app

I put together a more fair comparison by serving a simple webpack app. It takes 400ms until the table is fully rendered:

Going from 100 to 10,000 rows still takes 400ms:

For comparison button takes 332ms:

Scrolling

Another measure of performance are onScroll events which take 7.6ms on both sites:

Conclusions

In simple cases our virtualized table takes 68ms longer to load than a button. In more complex layouts this difference can be up to 700ms longer. The number of rows a virtualized table renders does not seem to impact performance. The time until interactive is the same as the time until rendered (when React renders an HTMLElement it adds event listeners to make it "interactive" too). I think the current primary performance bottleneck is the forced layout reflows used to calculate cell width/height. These take ~9ms total in the simple webpack app, but ~273ms on our docs site. I think we could assume a fixed height and look to enhance these lines upstream in react-virtualized.

Another thing that may help scrolling is batching removing/adding DOM nodes. Currently a lot of time is spent removing/adding individual nodes.

[tlabaj]

cc @dgutride