Performance hit from reflow and coordsAtPos

1

I’m doing some performance testing and analysis with a large amount of nodes (~1000) and the biggest hit to performance I can see is Reflows or Layout thrashing. It seems to be due to the use of getClientRects().

Here is what Chrome reports:

09%20PM
Screen Shot 2019-10-25 at 3.40.09 PM.png842×144 15.8 KB

It doesn’t have much information about why Layout is taking so long or what is causing it.

Here is what Firefox reports:

07%20PM
Screen Shot 2019-10-25 at 3.36.07 PM.png1069×471 78 KB

There’s more information here and it seems to suggest a reflow is triggered by the use of getClientRects.

This might need some sort of caching to not cause a reflow on every key press. Will look into this more but wanted to start a thread.

2

You can’t cache layouts across content changes (since those changes change the layout). Who is calling coordsAtPos and why in this scenario?

3

It was happening internally where state.scrollToSelection > prev.scrollToSelection in updateStateInner which sets a local variable scroll to equal “to selection” . This would then trigger this line to run:

scrollRectIntoView(this, this.coordsAtPos(state.selection.head), startDOM);

I’m not sure why this is being executed on every keypress, but even if I remove it I’m seeing reflows so maybe this is inevitable if content changes. In which case there’s not much that can be done to avoid it other than making the reflow faster.

4

To scroll the cursor into view.

Yes, if the DOM changes the browser has to compute a new layout. That is indeed inevitable.

5

Even if the cursor is already in view? I might look into this part further and report back.

But ultimately you are right, computing layout is going to be necessary when the DOM changes. There might be things I can do on my end to make reflows cheaper however.

6

You don’t know that it is until you find out where it is.