vscode-cpptools loads the processor 100%[VS Code 1.17, MacOS 10.13, vscode-cpptools 0.13.1]

[vvzvlad]

After update VS Code to 1.17, cpptools loads processor 100%:

What can I do to diagnose/fix this?

[sean-mcmanus]

That is normal behavior -- when Mac reports 100% CPU usage, it means on one core, so your other cores should allow you to work unimpeded. That process parses files for symbols under the workspace and other directories according to the browse.path setting in c_cpp_properties.json (viewable via doing an Edit Configuration command). You can remove directories under the browse.path or add a * to the end to make it non-recursive, which will cause less files to be processed. Let us know if you think there's some additional buggy behavior.

[mthomos]

I have the same issue in my laptop(Fedora 26 64bit). Without editing the file, at least one core is at 100% continuously. I wll disable it until the issue is fixed

[sean-mcmanus]

@mthomos It's not a bug. It's "by design". It's a background process that scans for symbols to add to our database to enable symbol searching, to go definition, etc. The browse.path and files.exclude settings can be used to configure it to do less processing. If you believe it's still a bug, we need more repro info, such as your c_cpp_properties.json settings.

[mthomos]

Where are the c_cpp_properties.json settings ?

[vvzvlad]

This is an unacceptable behavior for the editor who is open on the laptop, which means possibly a limited supply of energy. To load the entire core of the processor (even one) at all times, even when the IDE is in the background is a bad idea.
The number of my files in the project is finite, and the previous version did not need as much CPU time to scan them.

config_files.zip

[sean-mcmanus]

@mthomos Use the Edit Configuration command to generate the c_cpp_properties.json.
@vvzvlad The additional CPU usage may be due to bugs we fixed which could cause some files to incorrectly not be parsed. There are some things we can do in the future to finish faster, but we don't have control over how much CPU we use -- parsing a lot of files will always use a lot of CPU, just like compiling does. Once your browse database is finished being created, it should finish faster (although it will still rescan for differences between the file system and database the next time, which may also use high CPU). If you want, you could enable logging to see what processing we are doing and suggest ways to use less CPU: https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/Enabling%20logging.md , but definitely disable the logging afterwards, because logging a lot can slow it down.

[sean-mcmanus]

@vvzvlad There is a "bug" in your browse.path setting. The setting is recursive (unlike the includePath setting) but you have the ${workspaceRoot} paths specified multiple times which will cause duplicate processing. We haven't yet added code that checks for this and skips the duplicate work. You may want to add * to the end of the paths to make them not be recursive. The includePath usually will only point to headers, but the browse.path should point to source files as well.

[mthomos]

@vvzvlad i totally agree with you. Editing a small C project with VS studio drains by battery 2-3 times as much than editing it with Atom

[vvzvlad]

@sean-mcmanus I correctly understand that instead of this set of paths I can set one path $ {workspaceRoot}, and it will bypass all the inbuilt folders recursively?

           "${workspaceRoot}",
           "${workspaceRoot}/core",
           "${workspaceRoot}/core/sys",
           "${workspaceRoot}/unwired",
           "${workspaceRoot}/platform/unwired",
           "${workspaceRoot}/platform/common",
           "${workspaceRoot}/platform/unwired/common",
           "${workspaceRoot}/platform/unwired/udboard",
           "${workspaceRoot}/platform/unwired/udboard/cc26xx",
           "${workspaceRoot}/platform/unwired/udboard/cc13xx",
           "${workspaceRoot}/cpu/cc26xx-cc13xx",
           "${workspaceRoot}/cpu/cc26xx-cc13xx/dev",
           "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc26xxware/driverlib",
           "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc13xxware/driverlib",
           "${workspaceRoot}/platform/unwired/srf06/cc13xx",
           "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc13xxware",
           "${workspaceRoot}/platform/unwired/udboards",
           "${workspaceRoot}/unwired/asuno-light",
           "${workspaceRoot}/lib",
           "${workspaceRoot}/core/net/ip"

[vvzvlad]

@sean-mcmanus I deleted all other paths, but no, VS code says that I can not find many files and I suggest adding the path to them in the settings:

[sean-mcmanus]

@vvzvlad Yeah, you can either just use ${workspaceRoot} if you want it to recursively parse all the child folders, or you if want less processing, I would recommend removing the ${workspaceRoot} or using ${workspaceRoot}/* and just including the folders that have C++ files you care about. You definitely want to make sure large amounts of non-C++ files are not being looked at, because that will slow it down. What do the errors say in your Problems window? I can't tell if that's from the IntelliSense or browse engine.

[sean-mcmanus]

@vvzvlad Yes, you need all those paths in your includePath setting, but not your browse.path setting. includePath is not recursive. If the code action suggests you add a path, that means it found the path recursively from your browse.path setting, and you should add that missing path via the code action.

[vvzvlad]

Yes, indeed, with this configuration, the CPU load has disappeared.

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "/usr/local/lib/gcc/arm-none-eabi/6.2.1/include",
                "${workspaceRoot}",
                "${workspaceRoot}/core",
                "${workspaceRoot}/core/sys",
                "${workspaceRoot}/unwired",
                "${workspaceRoot}/platform/unwired",
                "${workspaceRoot}/platform/common",
                "${workspaceRoot}/platform/unwired/common",
                "${workspaceRoot}/platform/unwired/udboard",
                "${workspaceRoot}/platform/unwired/udboard/cc26xx",
                "${workspaceRoot}/platform/unwired/udboard/cc13xx",
                "${workspaceRoot}/cpu/cc26xx-cc13xx",
                "${workspaceRoot}/cpu/cc26xx-cc13xx/dev",
                "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc26xxware/driverlib",
                "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc13xxware/driverlib",
                "${workspaceRoot}/platform/unwired/srf06/cc13xx",
                "${workspaceRoot}/cpu/cc26xx-cc13xx/lib/cc13xxware",
                "${workspaceRoot}/platform/unwired/udboards",
                "${workspaceRoot}/unwired/asuno-light",
                "${workspaceRoot}/lib",
                "${workspaceRoot}/core/net/ip",
                "${workspaceRoot}/apps/serial-shell",
                "${workspaceRoot}/apps/shell"
            ],
            "defines": [],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "/usr/local/lib/gcc/arm-none-eabi/6.2.1/include",
                    "${workspaceRoot}"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "macFrameworkPath": [
                "/System/Library/Frameworks",
                "/Library/Frameworks"
            ]
        }
    ],
    "version": 3
}

[agauniyal]

What's wrong with it using 100% cpu core 😂 ? Let it finish the work faster..

[cdarken]

Same on my Antergos Linux system, installed PlatformIO Ide and without even creating a project, I get this

[sean-mcmanus]

@cdarken We had a bug that would cause all the default system header folders to be parsed in the open file scenario. It should be fixed in our pending update.

[bobbrow]

We released 0.14.0 with a fix for this. Please let us know if you continue to have issues.

[sean-mcmanus]

@mthomos We have a pre-release with the fix if you want to try it out (https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.14.6-insiders) and let us know if there are any fixes we should make before our release next week.

[mwheeler]

As someone who has been affected by this for months myself, I can say v0.14.6 preview looks a lot better.

My project (relatively large multi-million line C++ code base w/ quite a few thirdparty dependencies, including behemoths like boost/eigen/etc) has 77603 files that vscode.cpptools says it discovered/processes.

During the processing time, cpu usage is quite a bit lower (43% average in my case) - takes about 3-4 minutes to finally finish processing (previously it would never finish processing). This is compared to a constant 100% cpu load (which never went down, even after 24+ hours of me leaving the vscode/laptop open and seeing if it would ever finish) before 0.14.6 preview.

Having said all of that, I'd highly recommend adding better logging output (eg: periodic updates on how far along processing is (eg: 500/77000 files after N seconds, or something), and details on what work is being done in each intellisense server, which can be used to diagnose if it's actually stuck, or progressing slowly, and why).

I've experienced various 100% cpu usage scenarios w/ vscode.cpptools intermittently from reasons I can't diagnose - which has been incredibly frustrating on laptops (to the point of having dropped vscode entirely until this pre-release came along) - knowing exactly what files / what work was being done by the intellisense server, would help me raise bugs for these issues when they appear.

[sean-mcmanus]

@mwheeler We default to around 50% CPU usage when parsing non-active workspace files, but we decided to change the default back to 100% (unless enough users complain) and let users who don't like that to change the workspaceParsingPriority setting. In the "every day" scenario, your database should already be built and the processing should be a matter of seconds as it just scans the files/database for updated timestamps.

The hover info over the database icon should be pretty accurate now in terms of the processing/parsing (the files to parse will increase as it finds more #include non-workspace files to parse). More detailed info can be seen by increasing the C_Cpp.loggingLevel to a hidden number value, such as "6", but it lowers performance severely so you generally don't want to use that unless you're diagnosing a problem.

The "Updating IntelliSense..."/flame parsing (in the IntelliSense.Msvc process) doesn't have any logging/status reporting -- the expected scenario is that it completes in a matter of seconds (unless there's some infinite processing bug, e.g. #1294). Adding logging to that might be difficult because it is deep in the parser code for a particular translation unit. Fixing these issues is 100% dependent on us discovering an isolated repro that we can send to the team responsible.

It's still expected to use 100% CPU usage (on a different thread) when opening a file, which re-runs IntelliSense, or if there's a file opened that hasn't been parsed yet (or with a new #include).

[bobbrow]

An image for your reference. This is the database icon @sean-mcmanus is referring to on the right side of the status bar:

[zinechant]

It seems there is no such cute database icon in Linux. Only a red fire icon with the caption 'Updating IntelliSense...'.
Or are these two different phases of updating intellisence?

[sean-mcmanus]

@zinechant The database operation probably completed (unless some error occurred). If you open up a big enough workspace, you should see it appear. The database icon isn't "IntelliSense" -- it's the workspace symbol database parsing (appears on workspace opening, although a C++ command may need to be executed first for the extension to activate fully). The red flame is IntelliSense parsing of the current translation unit (appears on file open and after edits).