{
"activationTimes": {
"startup": false,
"codeLoadingTime": 102,
"activateCallTime": 5,
"activateResolvedTime": 0,
"activationEvent": "onLanguage:cpp"
}
}
After opening a cpp file, the extension uses 100% CPU until PC locks.
It should be 100% CPU on one core, which is normal, but what do you mean by "until PC locks"? Also, when you hover over flame and/or database icons in the bottom right what does it say? Does this repro with a simple file with no header? What if you do an Edit Configuration and clear out the includePath and/or browse.path settings?
Thanks fo your reply
but what do you mean by "until PC locks"?
I mean that after a while the pc starts swapping due to the high cpu and memory usage and the, once swap is full, it just hangs. Other times compiz crashes before swap starts (I'm on Ubuntu).
Also, when you hover over flame and/or database icons in the bottom right what does it say?
It says "Discovering files" but I'm unsure. It does not happen with every file. It seems that something in a specific source is actually triggering the issue.
Does this repro with a simple file with no header?
Nope
What if you do an Edit Configuration and clear out the includePath and/or browse.path settings?
Seems like the problem is still here.
I'm going to try the fix suggested in https://github.com/Microsoft/vscode-cpptools/issues/1294
I'll let you know.
How many cores and memory do you have? How much memory is released from your system when our extension is disabled? "Discovering files" should go away in a matter of seconds (I was seeing about 1500 files per second processed). We've had parser bugs that could lead to infinite loops, but they were fixed....oh wait, looks like https://github.com/Microsoft/vscode-cpptools/issues/1294 is a not fixed infinite loop I didn't realize we had.
I have 8 cores and 16GB of memory.
Is it ok that it indexes all the files every time I open the editor? Shouldn't it save the data to a DB?
Actually, it is much slower than that in indexing. I takes about 6/7 seconds to index 700 files.
I assume we're only using 1 core though, right? 16 GB should be enough. I don't know how we could be using up so much memory. I'm seeing the "Discovering files" phase process at a rate of 1500 files per second and the "Parsing files" phase go at 50 files/second when it actually does parsing and 75 files/second when there is no parsing, which appears to be too slow due to unnecessary #include file traversals -- we're working on a fix for that now.
Yes, it uses a single core.
I don't want to smile too early but it seems that the fix proposed for #1294 is working for me :-)
Thank you!
Oh, I didn't realize you were having 100% CPU usage on the IntelliSense process (I thought it was the main process for some reason...the intellisense process has nothing to do with the messages shown on the database icon).
same issue
On current macOS ~/.vscode/extensions/ms-vscode.cpptools-0.14.5/bin/Microsoft.VSCode.CPP.Extension.darwin starts hogging 100% of one CPU core as soon as I open a .c file.
@Jackson-soft What do you mean by "same" issue? Do you mean issue https://github.com/Microsoft/vscode-cpptools/issues/1294 ? Did the workaround work?
@vasa-chi Your issue is different. Microsoft.VSCode.CPP.Extension.darwin is not the IntelliSense process and it's supposed to be using 100% of one CPU core because it's parsing for symbols (or looking for files to parse). You can use the Pause Parsing command to temporarily stop this or set the browse.path setting in c_cpp_properties to be empty (or include less folders) to eliminate the CPU processing. We are working to reduce the length of time the CPU is used.
@sean-mcmanus umm, should it use 100% all the time? I've opened VSCode on one file for half an hour and got some tea, and it was still running at 100% when I got back to my macbook.
@vasa-chi What does the progress show when hovering over the database icon in the bottom right?
@sean-mcmanus "Parsing files 456 / 38292".
I got it, though. I've disabled limitSymbolsToIncludedHeaders in my config, and plugin started parsing _everything_ in possible includes. As soon as I enabled this option, everything returned to normal.
Or, at least, it seems to.
Thanks for help, and sorry for late answer.
@Jackson-soft if you can elaborate on what your issue is, we can help you. It looks like @vasa-chi's issue is resolved and @claudio-incomedia's issue is the same as #1294, so we will close this issue if yours is also the same. Thanks.

The IO usage is killing my system.
Unfortunately I have spinning rust and I think it's becoming a bottleneck when one core is run at full tilt.
parsing 19790/30690 (66%) (the number is slowly moving up)
@jamie-pate, we index your entire workspace by default. If our extension is causing an I/O bottleneck for you, you have some options:
Clicking the database icon only presents Pause Parsing from the quicklist
@sean-mcmanus, did we not add the option to change the parsing priority from the icon?
@jamie-pate, you can change the setting manually. It is "C_Cpp.workspaceParsingPriority"
Yeah, I never added that option...it was never even spec'd out. Maybe a Change Priority option could be added that triggers a 2nd dropdown with the list of available options.
I'm closing old issues marked "more info needed". If you are still having issues with the extension, please ensure you have installed the latest version and open a new issue with the issue details.
Could there be a "pause" button on indexing? This isn't a great UX, I ended up disabling the extension because I have work to get done and a lagging UI is pretty frustrating.
@Manouchehri If you click the database icon in the status bar you can select the "Pause Parsing" button, but it only works for background parsing, and not parsing caused by opening a file and parsing its include dependencies. But that doesn't affect the red flame (IntelliSense parsing) which happens in a different process.
Most helpful comment
same issue