Intermittent: Lag With Sticky Scroll After Prolonged Use

[SpicyRicecaker]

Describe the bug

I don't know how to fully reproduce this bug, but at some point the application becomes noticeably laggy, only when VSCodeVim is installed.

In this "laggy" state, when sticky scroll lines of code are visible (editor.stickyScroll.enabled must be set to true, which it is by default on VSCode) it becomes incredibly laggy to move the cursor.

This issue has been observed by another user in another performance issue thread:

I noticed that the laggy scrolling with j/k would happen more when the "sticky scrolling" pane would appear at the top, such as navigating within nested methods or HTML tags. Hiding the sticky scrolling section (right-click inside the pane, uncheck the option) significantly improved the performance of vim for me, in case that helps anyone else! Annoying to need to do this, but it was getting to the point where I was restarting the window at least once an hour.

Originally posted by @jhobz in #3957

To Reproduce

Again, I'm not sure how to reproduce the laggy state, but after using VSCode with the editor.stickyScroll.enabled setting set to true for some time (like 30-60 min?) moving the cursor under a visible sticky scroll line(s) will be excruciatingly slow.

(Again, while in the triggered laggy state) here's how to trigger the lag:

1. Create a new file using ctrl+shift+p and Create: new file...
2. Save file as lol.json
3. Paste some sort of nested json structure:

{
    "lol": {
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1,
        "lol": 1
    }
}

4. Scroll down until "lol": { is visible as a sticky scroll
5. Click j a few times, and observe insane lag

I tried this with a basic python and markdown file and observed the same behavior, and presume that any language that has sticky scroll should be able to trigger this lag.

Screenshots

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.30.1
• VSCode version: 1.102.0
• OS: Windows 11 24H2

Additional context

Very interestingly in the laggy state, when a file isn't saved or on disk, and the sticky scroller is visible, the performance lag doesn't occur.

For example, try doing the reproduction steps while in the laggy state, but skip step 3. Instead, click on the highlighted "Select a language" text in the editor, and select JSON. No performance lag is observed. But once the file is saved, the lag occurs.

Comments

I feel like sticky scroll + vim isn't that uncommon of a combination in VSCode, especially considering that sticky scroll is enabled by default. Admittedly this bug has brought me a lot of frustration with VSCodeVim before realizing sticky scroll may exacerbate the lag. Thanks for making this project, I don't know if I'll be keeping sticky scroll on to find the reproduction steps, but hopefully someone else is able to find this if they see the same issues.

[yhshin11]

Thanks for raising this issue. I saw similar behavior after updating to VSCode 1.102.0, didn't see improvement after updating to 1.102.1. Initially thought it might have something to do with new copilot features, but disabling sticky scroll seems to make the lag go away.

[feresr]

+1 I am also having this problem. A quick way to get out of this state in the meantime is to run> Restart Extensions Host

[rghassem]

+1 I get crazy slowdown after like 5 minutes in my typescript project. Unusably slow, fixed after restarting vscode but then back again in 5 minutes or so. Source files I'm browsing can be up to 200 or 300 lines of code sometimes, nothing unreasonable. Inspector showed sticky scroll using 100s of milliseconds per keyboard event, across many events triggering. I disabled it by right clicking on its widget at the top of the screen, and things seem back to normal. My guess is its registering a progressively larger number of button event handlers over time they add up. No idea why this would only happen when using VsCodeVim

[Protowalker]

+1 I'm having this problem and a quick look at the profiler confirms this is happening in stickyScrollWidget.ts

[scottm-blackmagicdesign]

I can also confirm that this problem exists, but does take some time to manifest.

The profiler shows stickyScrollWidget.ts is part of the problem, and when I disable editor.stickyScroll.enabled the issue is resolved. It appears that even just toggling editor.stickyScroll.enabled is enough to temporarily resolve the issue. There must be some leak with event listeners, as you can see after some time I have >100,000 listeners, whereas a fresh instance of VSCode has <5,000.

I haven't been able to yet confirm that this is related to related to VSCodeVim... Does anyone have any evidence to show that this is the case or could this just be a VSCode issue?

[jhobz]

I haven't been able to yet confirm that this is related to related to VSCodeVim... Does anyone have any evidence to show that this is the case or could this just be a VSCode issue?

I will say, as the person who first linked this to the sticky scroll header, I do still think there's more at play here than just the interaction of these two elements. While disabling sticky scroll has definitely reduced the frequency with which I run into the lag issue, it has not completely eliminated it. I will still sometimes get some fairly severe Vim lag after using VSCode for a while, often resulting in needing to reload the window to fix it.

[liamdawson]

If it helps, it's not just when I use vim keys — I also notice this lag when I click to move the cursor, both in normal and insert mode.

Restart Extensions Host does not help me.

[hoodnoah]

+1 also having this problem, my profile looks identical to scottm-blackmagicdesign.

Disabling stickyscroll seems to solve the issue.

[VanIseghemThomas]

+1 also the exact same as @scottm-blackmagicdesign and can also confirm that disabling sticky scroll seems to solve the issue for now like @hoodnoah said.

[mj2068]

i'm having the exact same issue with vscode neovim. i digged a little bit deeper, it seems like a more general issue. maybe related pr: Fix sticky scroll performance issue by using correct array for min content width calculation #252342 fun fact, open this issue, you'll see AI(copilot) and human are working together to fix the issue.

[aryla]

I opened a PR that fixes the event listener leak in vscode (two months ago): https://github.com/microsoft/vscode/pull/260020

I haven't been able to yet confirm that this is related to related to VSCodeVim... Does anyone have any evidence to show that this is the case or could this just be a VSCode issue?

I does happen even without VSCodeVim. VSCodeVim just triggers so many selection changes that it becomes a problem faster than without it.

[jhobz]

I opened a PR that fixes the event listener leak in vscode (two months ago): microsoft/vscode#260020

I haven't been able to yet confirm that this is related to related to VSCodeVim... Does anyone have any evidence to show that this is the case or could this just be a VSCode issue?

I does happen even without VSCodeVim. VSCodeVim just triggers so many selection changes that it becomes a problem faster than without it.

Legend

[ebebri]

me too. it was driving me insane for months. tried SO many different things. Then today I noticed the same as you, that when a header is present, that's when it happens. THEN an LLM could help me find the correct setting,

"editor.stickyScroll.enabled": false

and now it is finally gone. by seArching on the setting I found this.

this has seriously hampered my productivity for months since I was forced to swtiched to vs code from neovim. so grateful it's finally over, so much frustation!!