[seyedmostafahasani]

Summary:

ViewabilityHelper._onUpdateSync filtered the indices to check with this._viewableIndices.includes(ii), which is O(n) per index and therefore O(n^2) per update. This builds a Set of the current viewable indices once and uses has() for the lookup instead. Behavior is unchanged.

Changelog:

[INTERNAL] [CHANGED] - Use a Set for the stale-index lookup in ViewabilityHelper

Test Plan:

No behavior change. The existing ViewabilityHelper-test.js cases cover this path, in particular "minimumViewTime ignores stale viewability updates". Run with yarn jest packages/virtualized-lists/Lists.

Benchmark:

Micro-benchmark of the filter alone (Node v22; median of 9 interleaved rounds per size; before/after results verified identical). Typical case: every checked index is still viewable.

Viewable indices (n)	Before: includes()	After: Set + has()	Speedup
10	122 ns	363 ns	0.33x (slower)
30	680 ns	1.29 us	0.53x (slower)
50	1.85 us	2.30 us	0.81x (slower)
100	6.8 us	4.8 us	1.4x
500	151 us	19.3 us	7.8x
1,000	513 us	38.8 us	13x
5,000	12.5 ms	0.41 ms	30x
10,000	50.1 ms	0.93 ms	54x

When half of the checked indices have scrolled out of view, the gap is larger (for example 2.5x at n=100 and 97x at n=10,000), because each miss makes includes() scan the whole array.

Note: n is the number of items viewable at once, not the list length. The break-even point is roughly 50-100 indices. Below that, building the Set costs more than includes(), so for lists with only a few dozen viewable items this change is neutral to slightly slower. The gain shows up when many items are viewable at once, for example very small items, large windows, or large windowSize / viewAreaCoveragePercentThreshold setups. This is a micro-benchmark of the filter only, not an end-to-end scroll measurement.

[meta-cla]

Hi @seyedmostafahasani!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[javache]

_viewableIndices is often on the order of magnitude of 10, not 50, so your benchmarks show this wouldn't be beneficial. Perhaps if we computed this set inside computeViewableItems? Even then, it's probably a negligible win - data locality in arrays outperforms algorithmic complexity for small numbers.

[seyedmostafahasani]

Thanks for the review, and agreed on the numbers. In my benchmark the Set only breaks even at around 50-100 viewable indices (122 ns vs 363 ns at n=10, so ~3x slower there), and with _viewableIndices typically around 10 this change as written wouldn't help most lists.

I'll try your suggestion of building the Set once in computeViewableItems and measure end-to-end (a scroll benchmark in RNTester with small and large viewable windows) rather than just the isolated filter. If it doesn't show a clear win at typical sizes, I'll close this PR.

[seyedmostafahasani]

Thanks again for the review. I tried your suggestion and also looked at the call sites more closely.

Measured on the real ViewabilityHelper.onUpdate (scroll simulation over a 20k-item list, render range like VirtualizedList, median of 7 runs): building the Set in onUpdate instead of _onUpdateSync makes no difference, since it is built once per changed update either way. At ~10 viewable items none of the variants is distinguishable from the baseline (~16 us per update, within the +/-5-10% noise), so I agree it is negligible at typical sizes.

While reading the code I noticed the filter in _onUpdateSync looks like a no-op. Both call sites pass the same array that was just stored in this._viewableIndices, and the minimumViewTime timer already returns early when _updateGeneration changed (every reassignment of _viewableIndices bumps it). So the filter always keeps every index.

Instead of the Set, I'd change this PR to skip the filter when the input is the stored array:

if (viewableIndicesToCheck !== this._viewableIndices) {
  viewableIndicesToCheck = viewableIndicesToCheck.filter(ii =>
    this._viewableIndices.includes(ii),
  );
}

Behavior stays identical for any other caller, and all 22 existing ViewabilityHelper tests pass. Measured speedup vs. current main: ~1.0-1.1x at 10-50 viewable items (within noise), ~1.2x at ~200, ~1.6x at ~800. So the win only matters for very large viewable sets.

If you'd prefer removing the dead filter entirely, or think this isn't worth changing, I'm happy to do that or close the PR instead.