Describe the bug
The performance of the initial rendering of various editor modes seems to significantly differ.
By initial rendering I mean the moment a user switches between modes using the toolbar.
According to our observations and some measurements, the winner, interestingly enough, is the "edit" mode, while the absolute loser is, interestingly enough, the "resize" mode.
We clearly notice the difference with some huge pages we have here in our internal app, which has a bunch of custom plugins. So to rule out the plugin interference, I'll try to demonstrate using a standard example page.
The measurements show that the difference in performance is not caused by how long it takes for the component tree to reconcile (render), but how long it takes to commit it, which seems to be a function of the number of state altering side effects.
The best way to demonstrate the problem is by using the Timings feature of the Performance tab of Chrome Dev Tools. It uses the Timing API which was removed from the latest versions of React, so in order to reproduce the attached measurements you'll need to downgrade your React to 16.x (I used 16.14).
In the below screenshots I'm using cellSpacing example and simply switching between editor modes.
It makes a difference which mode you are switching from, so I took all measurements switching from "preview" to the target mode. When measuring "preview" performance I was switching from "edit".
I have some Chrome plugins enabled, so absolute numbers are useless. However, when compared to each other they seem to make sense.
The reconciliation phase is about the same in all the measurements, but the commit phase differs greatly.
The "edit" mode is the only one that doesn't seem to have any state altering side effects. Here is the graph for it:
"Insert" and "preview" modes seem to be about 50% slower, most likely because of some state altering side effect (cascading update warning):
The "move" mode is usually about 2 times slower, again with the cascading update warning:
And here's our champ, the "resize" mode:
It's usually 10-15 times slower than "edit"!
It shows the same mammoth number regardless of whether you enter or exit it.
The more plugins you have on the page, the bigger hit the "resize" mode sluggishness is going to take. Here is what we see in our case on a huge page with lots of plugins:
Another way to look at it is using a more standard React DevTools profiler. For 17+ React it is the only option. It lacks the cascading update warning, it doesn't clearly show you the time it took to perform the final stages of the commit, but you can tell the unhealthy cycle by the number of commits.
cellSpacing example page shows the difference of about 3x times more commits for "preview to resize" switch than "preview to edit" switch. This is a large number, but it's not that staggering. In our application, on a page with 120 plugins we have this:
Switching from "preview" to "edit":
And here is switching from "preview" to "resize":
It looks like a bunch of state altering size effects somewhere in or around
Resize mode clearly needs fixing, but it would be nice get rid of cascading update warnings across the board.
bug released released on @beta