Optimize VirtualizedList

[halaei]

Summary

Using FlatList components with 50 items, and the default values for initialNumToRender and maxToRenderPerBatch, the following happens:

• Render first 10 items (Items[0 .. 9]).
• Sleep.
• Render first 20 items (Items[0 .. 19]). It should be rendering items [10 .. 19] instead.
• Sleep.
• Render first 30 items (Items[0 .. 29]).
• Sleep.
• Render first 40 items (Items[0 .. 39]).
• Sleep.
• Render all items (Items[0..49]).

So the flat list is rendering the first 10 items 5 times. It is a performance issue when the items are complicated, or the FlatList has many items. Having N items the FlatList will render O(N^2) items over time.

This PR reduces time complexity by:

1. Adding a cache of cells to VirtualizedList and reusing the components in consecetive calls to list.render().
2. Making CellRenderer a React.PureComponent and re-shaping state to prevent re-renders.

Possibly related issues

• FlatList renders items way too often, resulting in poor performance FlatList renders items way too often, resulting in poor performance #29946
• FlatList and VirtualizedList Scroll performance is laggy after 30+ rows . [FlatList] FlatList and VirtualizedList Scroll performance is laggy after 30+ rows .  #13413
• VirtualizedList- inefficient function passing for CellRenderer VirtualizedList- inefficient function passing for CellRenderer #20174 (PRs: VirtualizedList CellRenderer optimization #21163, Experimental VirtualList Optimization #27115)
• FlatList rendering too much data, repeatedly FlatList rendering too much data, repeatedly #25825
• Flatlist continuous scroll heats IOS device Flatlist continuous scroll heats IOS device #25775
• FlatList Weird Behavior after appending new data FlatList Weird Behavior after appending new data #24825
• FlatList re-renders its items many times FlatList re-renders its items many times #24206
• FlatList's renderItem renders twice, instead of once FlatList's renderItem renders twice, instead of once #18396
  ...

Changelog

[JavaScript] [Fixed] - Don't render list items if not changed.

Test Plan

Some tests are needed to make sure that all the cached components are rendered just enough, no more/less.
Footer, header, and cell components are cached. Other child components don't need to be cached because they are either simple or rendered once.

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: a15a46c

[efstathiosntonas]

@halaei I've applied the patch and performance seems improved, I've faced an issue with SectionList though Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.. Nothing has been touched in that SectionList it was working perfectly before the patch.

[satya164]

It is a performance issue when the items are complicated, or the FlatList has many items.

Isn't that optimized by using React.memo/React.PureComponent for the individual items as recommended?

[satya164]

This component accepts props which changes every render, so I think PureComponent checks will be false every time:

• onLayout - can be fixed
• parentProps - can't be fixed
• Maybe more?

[halaei]

onLayout doesn't seem to cause extra renders in my manual tests. It's input value is given by the creator passed to _pushCell() function, which is only called when needed. So caching already is applied to onLayout too.

I think maybe for some use-cases there can be more optimization, for example not always everyone needs all the fields in parentProps, and sometimes the order and number of items in data doesn't change the internal of an item component, so maybe ii can be removed from deps too. I am interested to see other improvements done too.

[halaei]

Isn't that optimized by using React.memo/React.PureComponent for the individual items as recommended?

Simply wrapping the return value of renderItem() inside a React.memo or returning a React.PureComponent doesn't help:

const ItemComponent = (props) => {
    x =...
    y = ...
    z = ...
     return <ComponentDependingOn_x_y_z ...>;
}
const MemoItemComponent = React.memo(ItemComponent); // It doesn't prevent extra re-renders because props always change by each call to VirtualizedList.render().

However using memoiztion techniques inside the component prevents extra renders of the nested component ComponentDependingOn_x_y_z:

const UseMemoItemCompont = (props) =>{
    x =...
    y = ...
    z = ...
    return React.useMemo(() => {
        return <ComponentDependingOn_x_y_z ...>;
    }, [x, y, z]);
}

So I think this PR has the following values:
1.It lets developers write simpler code, because they won't need anymore to think about memoization techniques in their list components.
2. It is more efficient than using memoization in renderItem(), because it removes extra renders of parent/wrapper components in VirtualizedList and renderItem() itself.

[satya164]

It is more efficient than using memoization in renderItem(), because it removes extra renders of parent/wrapper components in VirtualizedList and renderItem() itself.

It's not safe to memoize a React Element. It could be using some state in the component which VirtualizedList doesn't know about, which will skip re-rendering even when it should re-render.

However, if it was something like ItemComponent which accepted a React component instead of a render callback, it would be safe to memoize that.

[halaei]

@efstathiosntonas

I've faced an issue with SectionList though Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

I tested with a simple SectionList and it worked for me. Also current tests are passed. Can you give an example SectionList that fails?

[bohdan145]

Any info about the status of this request ?
Is this gonna be merged any time soon?

[halaei]

I am also interested to have feedback. I've just checked this PR with master branch and PR #31401 for more tests. All tests passed.

[dev-arson]

Could You check this optimization on RTL mode? In RTL We don't have 'sleep' phase, and as You write should be work the same as in LTR mode, render initialNumRender first and sleep, render second , sleep. etc.
Maybe this optimization could be used for start fixing RTL issue with flickering @halaei @NickGerleman ?

[github-actions]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled for 7 days with no activity.