Significant VSCodeVim performance slowdowns tied to visible size of another extension's static TreeView

[alythobani]

Type: Bug

Summary

When using VSCodeVim and holding down a remapped key (e.g. j mapped to gj), cursor performance can degrade significantly, with keystrokes lagging and bottling up, depending on how much of another extension's TreeView is visible. The visibility-dependent lag occurs even if the TreeView's contents are static (unchanging as the cursor moves) and its extension doesn't appear to be actively running any code, suggesting the root issue may lie in VSCode's handling of visible TreeViews rather than in either VSCodeVim or the TreeView-providing extension.

Steps to Reproduce

(Screen recordings provided below for extra clarity)

1. Install the Vim extension and some other extension that provides a TreeView, e.g. Region Helper or JSON Tree View
2. Configure Vim to map j to gj and k to gk, via your VSCode settings:

settings.json

"vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["j"],
      "after": ["g", "j"]
    },
    {
      "before": ["k"],
      "after": ["g", "k"]
    }
  ],

3. If on a Mac, repro'ing may also require enabling key-repeating in VSCode as described in VSCodeVim's README
4. Open a file that has enough contents for the chosen TreeView to fill its containing sidebar
5. Ensure the chosen TreeView is open and small in size, e.g. taking up only the bottom 1/8th of the primary sidebar
6. Hold j or k for a few seconds each and observe reasonable cursor-moving performance
7. Resize the TreeView to fill up most of the primary sidebar (collapsing other views as needed, e.g. the built-in Outline view)
8. Hold j or k for a few seconds each, and observe significant lag and bottling-up of keystrokes; the cursor continues moving many lines even after releasing the key
9. Move the TreeView to the secondary sidebar where it can populate the entire sidebar
10. Hold j or k for a few seconds each and observe even more lag and bottling up of keystrokes

Screen recordings

In this screen recording, Region Helper provides a TreeView ("Full Outline"). I release j and start holding k each time the cursor visually reaches // #region Public properties. When the TreeView takes up most of the sidebar, you can see the cursor travels far past the goal point due to the lagged / bottled-up keystrokes. After expanding the built-in Outline view so that much less of the "Full Outline" TreeView is visible, the lag mostly disappears:

region.helper.jk.perf.mov

In this next screen recording, JSON Tree View has been installed (and Region Helper has been uninstalled). Similarly here, I release j and start holding k each time the cursor visually reaches around the second // #endregion mark. The lag is reduced when the built-in Outline is expanded and makes the JSON TreeView smaller. The lag then becomes most extreme when the TreeView is moved to completely fill the secondary sidebar:

json.jk.perf.mov

Note: this issue doesn't occur when holding down keys that haven't been remapped, e.g. - and + show no lag even with the TreeView at full-size:

region.helper.+-.perf.mov

json-tree.+-.perf.mov

The fact that the lag only occurs with remapped keys is likely related to VSCodeVim's internals. But regardless of what VSCodeVim is doing under the hood, it seems unexpected for its performance to be affected simply by resizing another extension's TreeView, especially when the TreeView's contents are static and its extension isn't actively running any code (e.g. selection change event handlers).

To corroborate this: I've confirmed that the issue persists even after I've removed all vscode.window.onDidChangeTextEditorSelection listeners from Region Helper's source code and repackaged/reinstalled the extension (with logs confirming no event handlers are running as the cursor moves). Likewise, examining the code for JSON Tree View, which seems to mainly consist of src/extension.ts and src/jsonTreeView.ts, I don't see any event handlers that could be the cause of the lagging here as the cursor moves.

Concluding thoughts

Apologies if this is a weird one to debug, or if it seems somewhat out of scope for VSCode itself, given that the repro I'm providing involves these extensions (Vim and a TreeView extension of your choice) and a specific config (the j => gj Vim mapping and possibly Mac key repeat enabling).

But, based on the nature of the bug itself, this seems much more like the root cause might lie in VSCode's infrastructure for extensions and/or TreeViews rather than in VSCodeVim or either of the example TreeView extensions.

In the meantime, as a workaround I'll keep Region Helper's "Full Outline" view at a smaller size in the primary sidebar, although it'd be more useful at full size. I don't use JSON Tree View (I only installed it for debugging and demo purposes) so there's no issue there. Ideally though, any TreeView could be kept fully expanded without degrading the performance of other extensions like VSCodeVim. I'm not sure what else might be affected by this behavior, but I thought it might be particularly useful to flag it in case it does impact other extensions or VSCode features beyond this specific repro.

Thanks so much for the awesome work on VSCode!

[alexr00]

@alythobani thanks for all the details! Would you mind trying this out with the tree-view extension sample's JSON outline and letting me know if you still see it with that tree view? I'm still suspicious that this is caused by the specific tree-views that you demoed with.

You should just be able to clone https://github.com/microsoft/vscode-extension-samples
cd into the tree-view-sample
npm i
F5

[alythobani]

Hey @alexr00 , no problem, thanks for looking into this! Yup, the issue still persists with the sample tree-view extension.

Without the sample extension, no lag:

without.json.tree.view.mov

With the sample extension's JSON outline, but only a few items in settings.json, no visible lag:

with.small.json.tree.view.mov

With the sample extension's JSON outline with a larger settings.json, a significant lag + bottling up of keystrokes:

with.large.expanded.json.tree.view.mov

But interestingly the lag only occurs after I expanded the many-children vim.normalModeKeyBindingsNonRecursive tree item in the sample extension's JSON outline. With it collapsed, no lag:

with.large.collapsed.json.tree.view.mov

All these demos are with Region Helper and JSON Tree View both disabled (the extensions I demo'd when filing this issue). But as with those extensions' tree views, this lag does also depend on the visible size of the sample extension's tree view:

visible.size.dependence.mov