Repository navigation
bug: appendChildSlotFix makes each appended child element slower to add than the element added just before it #6973
Description
With appendChildSlotFix turned on, Stencil replaces appendChild and insertBefore on components that use slots without shadow DOM. Each call checks all of the host's existing children to find the slot the new node belongs in, then checks them all again to work out where to insert it. So doubling the number of children makes appending them take three to four times as long.
Reproducible here: https://github.com/denodell/stencil-slot-append-repro
It has two components that are identical apart from shadow DOM. On my machine with the CPU slowed down 4x in Chrome 155, appending children one at a time took the following time for me:
| # child nodes | shadow: false |
shadow: true |
|---|---|---|
| 250 | 310ms | 3ms |
| 1,000 | 3,111ms | 3ms |
| 2,000 | 13,818ms | 13ms |
With appendChildSlotFix: false, neither column's results exceed 20ms.
The docs say the slot fixes are meant to become the default in v5, which would affect any component that uses slots without shadow DOM.
Possible fix: keep track of which slot each child belongs to, and the last node in each slot, so appending a child doesn't need to search the existing children each time.
Stencil v4.45.2
Happy to help write or test a PR if you like.
Activity
denodell commentedon Oct 28, 2026
I have a bit of a correction to my suggestion above, thanks to the Ionic team's profile in ionic-team/ionic-framework#31658.
In the replaced
appendChildfunction, most of the time is taken up within theupdateFallbackSlotVisibilitycall at the end. That walks every child node and its descendants again after each item is inserted. Caching the last node per slot, as I suggested, only saves a relatively small part of the total time.In a quick test I did with my CPU slowed down 4x, appending 2,000 children to
<light-list>took 19.7 seconds, 18.2 seconds with the last node cached (not much difference), and 2.7 seconds with theupdateFallbackSlotVisibilitycall removed (this is where any attention should go to fix the issue, I think).Could the replaced
appendChildupdate only the fallback for the slot that changed, or skip the check when that slot already had slotted nodes? Its fallback content would already be hidden in that case. Happy to discuss further.