Bugzilla

(Side note: my profile in comment 16 is using 0.1ms as the sampling interval, so the sample counts might be higher than normal.  Don't be fooled into thinking sample-count = milliseconds as it often would be by default.)

Here's our call to "set Node.textContent" in that profile of my testcase 1:
https://share.firefox.dev/3wXwtjY

There's one long burst of `set Node.textContent` activity for each button press, ~170ms each, nearly all of which is spent in frame destruction.  (And then it's followed by a ~200ms restyle which is really just reconstructing all those frames we just destroyed).

If you look down the callstack of where we're spending time there, you can see there are several nested `MaybeRecreateContainerForFrameRemoval`, each of which indeed decides to recreate the container frame.  Each level that we go down the callstack there, we're actually walking *up* the frame tree.  Here's how our analysis goes:
1) We trivially have to recreate the table contents (because its `textContent` was changed, i.e. the entire guts of the table are being replaced).
2) Since we're reframing the table-contents: that makes us consider whether we should recreate the table itself, and we decide that we should.
3) Since we're (temporarily) removing the table: that makes us consider whether we need to recreate the table's containing-block, since the table is part of an IB split (and removing the table removes the need for that IB split). And we decide that we should.

Parts (2) and (3) are both silly for the reasons emilio noted in comment 13.

(Side note: my profile in comment 16 is using 0.1ms as the sampling interval, so the sample counts might be higher than normal.  Don't be fooled into thinking sample-count = milliseconds as it often would be by default.)

Here's the time spent in "set Node.textContent" in that profile of my testcase 1:
https://share.firefox.dev/3wXwtjY

There's one long burst of `set Node.textContent` activity for each button press, ~170ms each, nearly all of which is spent in frame destruction.  (And then it's followed by a ~200ms restyle which is really just reconstructing all those frames we just destroyed).

If you look down the callstack of where we're spending time there, you can see there are several nested `MaybeRecreateContainerForFrameRemoval`, each of which indeed decides to recreate the container frame.  Each level that we go down the callstack there, we're actually walking *up* the frame tree.  Here's how our analysis goes:
1) We trivially have to recreate the table contents (because its `textContent` was changed, i.e. the entire guts of the table are being replaced).
2) Since we're reframing the table-contents: that makes us consider whether we should recreate the table itself, and we decide that we should.
3) Since we're (temporarily) removing the table: that makes us consider whether we need to recreate the table's containing-block, since the table is part of an IB split (and removing the table removes the need for that IB split). And we decide that we should.

Parts (2) and (3) are both silly for the reasons emilio noted in comment 13.

(Side note: my profile in comment 16 is using 0.1ms as the sampling interval, so the sample counts might be higher than normal.  Don't be fooled into thinking sample-count = milliseconds as it often would be by default.)

Here's the time spent in "set Node.textContent" in that profile of my testcase 1:
https://share.firefox.dev/3wXwtjY

There's one long burst of `set Node.textContent` activity for each button press, ~170ms each, nearly all of which is spent in frame destruction.  (And then it's followed by a ~200ms restyle which is really just reconstructing all those frames we just destroyed, and then a bunch of time spent reflowing those freshly constructed frames, and some DevTools work to account for the fresh geometry since I had devtools open.)

If you look down the callstack of where we're spending time there, you can see there are several nested `MaybeRecreateContainerForFrameRemoval`, each of which indeed decides to recreate the container frame.  Each level that we go down the callstack there, we're actually walking *up* the frame tree.  Here's how our analysis goes:
1) We trivially have to recreate the table contents (because its `textContent` was changed, i.e. the entire guts of the table are being replaced).
2) Since we're reframing the table-contents: that makes us consider whether we should recreate the table itself, and we decide that we should.
3) Since we're (temporarily) removing the table: that makes us consider whether we need to recreate the table's containing-block, since the table is part of an IB split (and removing the table removes the need for that IB split). And we decide that we should.

Parts (2) and (3) are both silly for the reasons emilio noted in comment 13.