Optimize editor for input latency

[Tyriar]

I recently did an exploration into input latency and found it can get pretty bad on slower machines. A lot of the problem is related to how we use synchronous event emitters/listeners work, performing their work after keypress but before the animation frame.

My proposal to improve is:

1. Review the most time consuming event listeners. If they are clearly safe to be performed at a later time without worrying about race conditions being introduced., move them to use an asynchronous event listener to be performed after the animation frame. For example UI updates like activity bar badge and tab indicator when an editor becomes dirty
2. Review all events and their listeners, defer as much as possible to after the animation frame. One way of doing this is for each important event to have both a sync and an async event. It's unclear how much we can move exactly, but when we do this we need to be extremely careful to not introduce text buffer-related race conditions as there are some assumptions made that we may be breaking by doing this
3. Setup development tools and/or telemetry to easily track measuring latency, I created https://github.com/microsoft/vscode/tree/tyriar/measure_latency to demonstrate a technique to approximate input latency
4. Come up with a plan for how we can prevent regressions for this critical path code

Tentatively assigning to October

[bpasero]

The core listener for text editors to react on content changes is:

• vscode/src/vs/workbench/services/textfile/common/textFileEditorModel.ts

  Line 565 in da506e9

  this._register(model.onDidChangeContent(e => this.onModelContentChanged(model, e.isUndoing || e.isRedoing)));

• vscode/src/vs/workbench/services/untitled/common/untitledTextEditorModel.ts

  Line 361 in da506e9

  this._register(model.onDidChangeContent(e => this.onModelContentChanged(model, e)));

These drive a ton of things on top such as:

• dirty state indication throughout the UI (only when dirty state changes, not on every content change)
• editor auto save
• editor backups
• etc (anyone using onDidChangeDirty and friends)

I wonder how an async emitter would help here: yes, it would take away lag from the first character typing when the editor transitions into being dirty, but eventually we have to pay the price, so the lag would just happen later? Or is the idea to delay the event literally on idle time?

[Tyriar]

@bpasero oh I missed the question there. The idea is to delay it until shortly after via setTimeout, so the text change should appear asap and the dirty indicator (as an example) would appear 1 or 2 frames later. ie:

Current:

• keypress task:
  • handle dirty change
  • schedule various things (backup, auto save, etc.)
  • other less critical updates (bracket pair parsing?)
  • render

Desired:

• keypress task:
  • handle dirty change
  • render
• following task:
  • schedule various things (backup, auto save, etc.)
  • other less critical updates (bracket pair parsing?)
  • render (whatever changed in this task)

There's some nuance here in what should be handled in the keypress task. For example currently the suggest widget is moved and updated in the keypress task. What we probably want is for the suggest widget to move in the keypress task but defer updating as it can be very expensive. Things like this we'll need to experiment with to see if splitting it up ends up with a worse UX and should be on the critical path.

We may be able to optimize the list's splice method as well to help here, haven't looked at the impl yet but it seems to do a lot of work and also affects search performance/ui responsiveness I saw last week.