Scrolling in a notebook diff editor is sluggish

[kieferrm]

When you have a reasonably sized notebook (around 30 cells) with changes and you open the notebook diff editor from it in the SCM view, scrolling in the notebook diff editor is very slow. For example, grab the scrollbar thumb and drag it up and down.

[rebornix]

We should apply the same optimization we did in the notebook editor in the diff editor too

• reuse code editors, diff editors for the cell input, metadata or output. Leverage the list template
• static layout code editor and diff editor
  • test that our listeners to content size change of the diff editor still works

[rebornix]

Perf chart before any optimization: when scrolling fast, we often see this 200+ms scrolling handler which tries to build editors again and again, which measures the size of the DOM element and triggers forced reflow

The first thing to do is reusing editors for the same type of list item, to avoid creating and disposing over and over again. After leveraging list view template, the perf chart now looks like

There are still some red dots there, meaning there are still forced reflow. Zooming in and we found that they are triggered by creating overview ruler (canvas) on every DOM resize. Since we don't want the overview ruler to be rendered for every individual embeded diff editor, we should add an option to disable the unnecessary rerendering.

[rebornix]

After disabling the overview ruler redundant rendering, we came to this flame chart

After triggering a mouse scroll (I'm using MX Master so it scrolls quite a bit), before it stops scrolling, it will render multiple pages of the diff view. From the chart above we can see that there is a 200ms task, which makes the scrolling noticeable sluggish. It's not doing anything wrong but just trying to render monaco editors. On a relatively large monitor (say 27", 150% scale), there would be around 20 monaco editors in the viewport if every cell is single line. Creating tens of monaco editor instances can easily cost hundreds of milliseconds.

Since we can't decide how many editors will be rendered, let's push monaco editor rendering to its limit. In VS Code, each regular monaco editor will initialize 50+ contributions (or plugins), if we only load the necessary ones (suggest, code snippet, accessibility) and we can save tens of millisenconds.

Most scroll handlers finish within 120ms and half of them are even below 50ms, considering that performance tracing amplifies the slowness, we can get a refresh rate at around 15to 30. For example, when I do a javascript performance profiling (which has less interference to the rendering), we can have 14 scroll event handling within 400ms with the same machine set up