Skip the VirtualizedList cells update when the render window is unchanged

[tomekzaw]

Summary:

VirtualizedList._updateCellsToRender runs for every scroll event, layout event and batch tick. It calls setState with an updater that recomputes the render window and returns null when nothing changed, which is most of the time while scrolling. The list itself doesn't re-render then, but for a class component setState always schedules a render pass, and React still has to run it to find that out. On a Galaxy A16 each of these passes takes about 4.5 ms. In a long feed with many mounted rows, those no-op updates were about 60% of all React updates during scrolling.

This change moves the updater's computation into a static _computeCellsUpdate(list, props, state), calls it before setState too, and returns early when it returns null. The early return only applies when it gives the same answer as the updater would:

• No other state update of the list is pending. Otherwise this.state is behind the state the updater will see. _hasPendingStateUpdate is set before each setState and cleared in the updater.
• The list has a viewport and content size. Before that, layout callbacks arrive back to back (onLayout, then onContentSizeChange). The updater of the first call runs after both and sees the later metrics, so skipping that call would lose a batch.
• _hiPriInProgress is cleared on an early return. It is normally cleared in componentDidUpdate, which doesn't run without an update. Leaving it set would push the next high-priority update onto the batching timer.

A first version without these conditions changed 8 snapshots in VirtualizedList-test.js (render windows expanding one batch later). With them, all tests pass unchanged.

Changelog:

[GENERAL] [CHANGED] - VirtualizedList: Skip the cells state update when the render window doesn't change

Test Plan:

• yarn jest packages/virtualized-lists: 203 passed, 1 skipped, 69 snapshots unchanged. The new test, "does not update state on a scroll that keeps the render window", fails without the change.

• yarn flow check, eslint and prettier pass.

• Measured in a production app: React Native 0.86, release build, Galaxy A16, Perfetto. Each run traces 15 flings (about 30 s), interleaving runs with and without the change. Medians:

  Profile feed (text, image and video rows), 5 runs each:

  	before	after
  React updates	312	140	−55%
  time in React updates (JS thread)	4.34 s	3.39 s	−22%
  JS thread CPU	6.32 s	5.49 s	−13%
  views created	1,896	1,896	same content

  Home timeline, 6 runs each:

  	before	after
  React updates	372	147	−61%
  time in React updates (JS thread)	5.14 s	4.13 s	−20%
  JS thread CPU	6.93 s	6.00 s	−13%
  views created	1,834	1,833	same content

  UI thread and RenderThread CPU are within 2% in both. Opening a screen with the list (3 runs each) creates the same 849 views with the same number of React updates, so the initial fill is not delayed.

🤖 Generated with Claude Code

[javache]

Duplicating React's own bookkeeping in _pendingStateUpdates does not seem like the right solution here.

It's more important that we ensure that state updater returns the same object identity when nothing meaningfully changed to avoid the re-render?

[tomekzaw]

@javache Thanks for taking a look! I agree the extra bookkeeping doesn't sound good. However identity alone doesn't really get rid of the cost here:

• In the no-op case the identity is already preserved: the updater returns null, and getDerivedStateFromProps returns prevState when the item count hasn't changed. So the list itself doesn't re-render; instrumenting the renderer, each of these passes visits ~450 fibers and bails out of all but 2.
• The cost is the render pass itself. For class components enqueueSetState always calls scheduleUpdateOnFiber; only useState's dispatchSetState has the eager Object.is bailout. On a Galaxy A16 each of these passes takes ~4.5 ms (almost all render phase: bailout traversal and context-change propagation), and a 30 s fling through a long feed has ~200 of them, so ~0.9 s of JS thread time.
• So the only way I found to avoid it is to not call setState. The pending-update tracking is there for the same reason useState's eager bailout requires fiber.lanes === NoLanes: this.state is only a safe basis for the comparison when nothing is queued.

I'm happy to iterate on the PR. We have two options:

1. A single "cells update queued" flag instead of the id set
2. Keeping the render window in instance fields and calling forceUpdate only when it changes, which removes the stale-state problem altogether

Would either of those work better for you?

[javache]

A single flag would be a reasonable trade-off. Let's move the state-updater to a standalone function too, so we can prove it does not depend on anything in the update payload?

Higher-complexity and riskier, but we should also evaluate moving this to a functional component so we can leverage the earlier bailout as follow-up.

[tomekzaw]

A single flag would be a reasonable trade-off. Let's move the state-updater to a standalone function too, so we can prove it does not depend on anything in the update payload?

Thanks for the suggestion! Done in 2af2fd0. I will re-run the benchmarks and update PR description.

edit: Done

Higher-complexity and riskier, but we should also evaluate moving this to a functional component so we can leverage the earlier bailout as follow-up.

I'm happy to do that in a follow-up.

[meta-codesync]

@javache has imported this pull request. If you are a Meta employee, you can view this in D125663171.