Preact: Unnecessary unmounting/mounting children with keys

[yishn]

Hi all, I'm the author of tikzcd-editor and am experiencing severe performance degradation after updating Preact recently.

tikzcd-editor is rendering a grid of elements onto the viewport; we only render visible grid cells. The user can use the pan tool to pan the grid, so cells outside of the viewport need to be added while panning, and cells that go outside of the viewport get removed.

Each grid cell will be typeset using MathJax on every change, which is expensive, that's why every grid cell has a key set to its coordinates, so we avoid rerendering while panning. This worked fine in v10.4.1, but in v10.4.2 and the latest version v10.5.3, we experience a lot of unnecessary rerenders.

Reproduction

Steps to reproduce

Here's a deployment of tikzcd-editor with v10.5.3 with a sample diagram. When trying to pan the viewport, you can see it's not smooth at all. When opening the Devtools you can see that Preact is unnecessarily unmounting/mounting elements.

Expected Behavior

Visible children should not be unmounted/remounted like in v10.4.1:

Actual Behavior

A lot of unnecessary unmounting/rendering of children as experienced in v10.4.2 and v10.5.3:

[marvinhagemeister]

Probably related to #2619

[darsain]

Was told my issues is related, so here is my case report:

Whenever you remove an uncertain number of elements from a keyed list, the elements after them get remounted. The number seems to differ between environments. On my local app it's 20+, on the isolated example below it's 50+.

Here is a visualization of the issue. Elements that get remounted flash red. The last 20 items should never flash, as only range 20-80 is being toggled:

This doesn't happen for smaller amount of items being removed:

The issue is isolated here: https://codesandbox.io/s/cocky-joliot-9gw5v

[pavulon]

In your case @darsain, the magic number is more than a half. Probably this has something to do with it.

[developit]

Echoing from various discussions elsewhere: the j/2 child search optimization was never supposed to apply to keyed matches, which to me makes this a bug rather than just a performance degradation.