Vscode-cpptools: Intellisense Progressively Gets Slower

[sborkowski]

Type: LanguageService

OS and Version: Windows 10 - Home Edition
VS Code Version: Latest
C/C++ Extension Version: Latest

Details

When I first open VSCode, intellisense runs perfectly fine and takes almost no time to come up. As changes to files are made, and as I build and rebuild the source, intellisense gets progressively slower. The little flame icon shows up at the bottom more often and for longer periods of time, eventually getting to the point where typing each character triggers the flame and intellisense is virtually unusable. I have to finish typing and wait for the flame to go away.

If I close VSCode and open it again, I can reset the intellisense to at least be useful again, but only for a short period of time. This is really annoying.

To Reproduce

c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
        "C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.1A\\Include",
                "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include",
                "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\crt\\src",
                "C:\\Program Files (x86)\\Windows Kits\\8.0\\Include\\shared",
                "${workspaceFolder}\\dev\\src\\**"
            ],
            "defines": [],
            "intelliSenseMode": "msvc-x64"
        }
    ],
    "version": 4
}

Expected behavior

It really should not take this long for intellisense to come up, especially since first opening VSCode, it seems to run just fine. It shouldnt really be rebuild the whole database either. Includes from CRT and VC
should be built once and then never again as those never change.

[sean-mcmanus]

Is this issue occurring with our latest Insiders build, i.e. via setting C_Cpp.updateChannel to "Insiders" or manually installing it from the vsix at https://github.com/Microsoft/vscode-cpptools/releases ? We fixed a known memory leak with that build. If it's not fixed with that, we're working on another fix for February that should reduce IntelliSense memory usage and processing time.

Do you know if it repros with smaller workspaces or with "**" removed?

[sborkowski]

As far as I can tell, updating and removing the "**" seems to have fixed the issue.

Thanks.

[xndc]

I'm getting this issue, or a similar one, with both the latest default build and the latest insiders build (0.22.1, apparently?).

Doing regular code editing actions - opening files, ctrl-hovering and requesting completions - will cause IntelliSense to gradually slow down to a crawl. Sometimes it takes 10 minutes to become noticeable, sometimes 30 minutes, and sometimes hours. All of these actions will eventually become unbearably slow, and the red IntelliSense icon in the bottom-right corner will go from blinking for half a second to being visible for 10 to 20. Autocomplete will simply not work at all while IntelliSense is busy. Restarting the editor fixes it.

I've been trying to put together a good "minimal" repro example - see here for something similar to the project I'm getting this on - but this issue is fairly hard to pin down. It takes a very long time to get it to deliberately happen, I've only managed it a few times (in 5-10 minutes) and it's extremely hard to tell which actions affect it and which don't.

It seems related to how many files IntelliSense has looked at during the current editing session, rather than how many individual actions (like requesting completions or ctrl-clicking) I've done, but that's only a guess. It doesn't seem related to memory - memory usage hovers at 700 MiB when idle for me regardless of how slow IntelliSense is.

Something I've been seeing in the debug log that might be related is that the extension will, when I ctrl-hover over something, "queue_intellisense_update" for files that it presumably should have information for already. If I hover on glfwWaitEvents, for instance, the extension will always queue an update for glfw/src/context.c. It will also always queue an update for the current file when I start typing to get completions.

Please let me know if there's anything specific I can do to debug this and help you fix it.

[bobbrow]

Thank you for the additional information. This is something we are looking at. We recently came up with a repro case and will start with that.

[Foxhoundn]

This is happening to me as well and it's a bit frustrating since closing VSCode and reopening does not seem to help, not even killing all Code Helper processes (which are the ones taking 150% CPU when VSCode is stuck on "Loading...").

Only a machine restart will fix this. Is there any way to run a new clean instance of VSCode without restarting? I am on the latest MacOS.

[sean-mcmanus]

@Foxhoundn What process is using CPU? There shouldn't be anything with our extensions that requires a machine restart to fix.

[jake-freeman]

I am also seeing this issue, it seemed to have gotten significantly worse after the VS Code 1.34.0 update. My Cpp config is bellow:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "/usr/local/include",
                "/home/vagrant/Qt/5.9.6/gcc_64/include",
                "/home/vagrant/Qt/5.9.6/gcc_64/include/QtCore",
                "/home/vagrant/Qt/5.9.6/gcc_64/include/QtGui",
                "/home/vagrant/Qt/5.9.6/gcc_64/include/QtQuick",
                "/home/vagrant/Qt/5.9.6/gcc_64/include/QtNetwork",
                "/home/vagrant/Qt/5.9.6/gcc_64/include/QtQml",
                "${workspaceFolder}/Inc"
            ],
            "defines": [
                "RELEASE=1",
            ],
            "compilerPath": "/usr/bin/clang",
            "cStandard": "c11",
            "cppStandard": "c++14",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}

Let me know if there is any other information you would like!

[andreeis]

Does IntelliSense still get progressively slower with the last insiders? We made a fix that may have addressed this issue but we don't know for sure since we weren't able to create a good repro for this scenario.

[lumonix]

I appear to have this issue too _sometimes_.
When restarting vscode the intellisense is very smooth / instant.
After ~ 30 minutes it takes several seconds for it to figure out auto-complete.
I've disabled cpp_tools semantic colorization too, because it too gets progressively slower in those cases.

Surface Book 2, 13.5-inch, 8GB ram, gtx 1050.
Ubuntu 19.10 (latest updates)
vscode 1.36.1
cpp_tools 0.24.0

I've not noticed it as much on my work machine (Redhat 7.x, 120 GB ram) running same vscode versions, but did notice semantic colorization makes the text editor slower after an hour of use.

I also did a test where I edit code actively for about 10 minutes and then let my computer sit idle for an hour with vscode open. When returning to edit code, intelli-sense is still fast. (But I haven't figured out yet what triggers the slowness)

Edit: tried to find some sort of repro today, but intelli-sense worked fine several few hours. So still not clear what occasionally causes it to slowdown requiring a restart of vscode.

Edit2: Got the slowdown again today and kept a closer eye on RAM. But RAM was only 4.9gb / 8gb. So it doesn't appear to be a RAM issue.

Cpp config:

        {
            "name": "Linux",
            "includePath": [
                "/usr/include",
                "/usr/local/include",
                "/usr/include/x86_64-linux-gnu/",
                "/usr/lib/gcc/x86_64-linux-gnu/8/include",
                "/usr/include/gtk-3.0",
                "/usr/include/glib-2.0",
                "/usr/lib/x86_64-linux-gnu/glib-2.0/include",
                "/usr/include/pango-1.0",
                "/usr/include/cairo",
                "/usr/include/gdk-pixbuf-2.0",
                "/usr/include/atk-1.0",
                "${workspaceRoot}",
                "${workspaceRoot}/src",
                "${workspaceRoot}/src/plugins",
                "${workspaceRoot}/include",
                "${workspaceRoot}/include/plugins",
                "${workspaceRoot}/modules",
                "${workspaceRoot}/build/linux"
            ],
            "defines": [
                "_DEBUG",
            ],
            "intelliSenseMode": "clang-x64",
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++11"
        }

[iagormoraes]

Same thing here on a MacBook Pro 2018, it takes 30 seconds on average to show something, each update it gets worse.

[aiQon]

Can confirm, am on Dell XPS15 9570 with Linux, after some time it becomes super slow. Only solution is to restart the whole machine. If I can provide something to help resolving it, I would gladly do so. VSCode with intellisense is my main driver.

Edit: It is not only VSCode that becomes slow, the whole box suffers.

[sean-mcmanus]

@aiQon That doesn't sound like an issue with our C/C++ extension, right? If you close VS Code and there are no cpptools or cpptools-srv processes running, then our extension cannot cause your machine to become slow.

But if you see dangling processes using memory still, that could cause the slow down. You should kill any dangling processes.

[rob-evercoast]

This is still happening for me. I have a 16 core machine and intellisense will max one cpu to 100% and freeze VSCode IDE completely.

As discussed in 2019 posts;

• it gets progressively worse over time.
• it gets worse much faster if you run gdb sessions to debug.
• it gets worse with large projects.

Why does the IDE lock up so badly that you can’t even move the cursor?

It’s getting to point where I may have to change C++ IDE to get around the issue - I’ve been using Microsoft VS exclusively since 1999, but need VSCode for Linux.
I don’t take changing from an MS IDE lightly.. That’s how hard it is to work when you can’t use your keyboard 😀

[sean-mcmanus]

@rob-evercoast That is most likely not a bug with our C/C++ extension -- our extension doesn't run code that can freeze the IDE via using 1 core (using 1 core for IntelliSense is normal, one of your 15 other cores should be able to render the UI, etc.). The VS Code UI renders in a different process from all our code and there is no code that VS Code blocks on our results. Or you're system is running out of memory. Or your Linux OS has issues. You can verify if it's our bug or not via disabling our C/C++ extension. It may be a bug with the VS Code syntactic colorization, which can freeze the UI if it hits a bug. I don't think anyone on our team on our multiple different computers and VMs with less than 16 cores has encountered VS Code UI freezing caused by our extension. The VS Code IDE has a profiler tool at Help->Toggle Developer Tools->Performance that you may be able to use to see what is causing the performance problems on your machine.

[bobbrow]

This discussion has forked a few times since the original issue from 2019. We believe we have addressed the original issue, but there are new reports that could each be different issues. In order for us to make forward progress on them we will need to ask those who are still encountering them to open a new issue with their repro details so that we can investigate. Thank you!