How to limit cpptools memory use

[PJH0x0]

It is very bad memory use when I open android open source project with vscode

[sean-mcmanus]

It is not expected for the cpptools process to use a lot of memory under normal conditions. It's possible too many files/folders are getting indexed. You could try adding folders to the C_Cpp.files.exclude setting to scan less files for global symbols. If you set C_Cpp.loggingLevel to "Debug" the logging might indicate what processing is occurring that could be contributing to the memory usage. We have settings like C_Cpp.maxMemory you could try, but I don't believe that would help in your situation.

[madscientist42]

"It is not expected for the cpptools process to use a lot of memory under normal conditions. It's possible too many files/folders are getting indexed."

That's quite an assumption there. It's showing hubris. What the heck is, "too many files/folders"? Honestly, let's ask a slightly differing question of you instead...

What happens when you have a Yocto build system where you need both the Yocto bitbake extension and the C/C++ one because you're doing code dev like you're really supposed to using Yocto? I can tell you.

It finds the literally thousands of project source files for each one of the tooling build-outs for the final image recipe and tries to index them with disastrous results. The very thing you claim isn't normal conditions. I'll own that it might not be, "normal," for what you're thinking of- but it's normal for Embedded Linux dev use. It's the tool path and workflow that was developed for it by the Linux Foundation at this point in time.

My machine? 32 GiB of RAM. 64 GiB of NVMe Gen3 backed swap. Your little tool has taken to curb stomping my box so I can't use it at-all for my workflows.

There should be an explicitly documented means to nerf this as asked for. There should, additionally, be actual limits, set somewhat low, that a user can override, also documented well, that keep it from curb-stomping systems.

I can see this extension curb-stomping low-spec systems under somewhat regular circumstances as I find at least part of the key settings that your code doesn't fully seem to honor to be set to eat the whole of the available system memory. C'mon...seriously?

[sean-mcmanus]

@madscientist42 An example of "too many files" might be the root "/" drive (see #11993 ). You should add build output folders to the C_Cpp.files.exclude setting.

[bobbrow]

Hi @madscientist42,

I recognize your scenario from the Reviews page. Would you like to schedule a call with me and we can review what's going wrong with your workspace? We're not experts in Yocto and I'd like to understand how you're configured so we can make sure everyone using Yocto has a good experience.

This is our public support email address: c_cpp_support@microsoft.com. Write me a message there and we can coordinate a time that works for you.

Thanks,
Bob

[stellarpower]

It's not uncommon for me to see CPPtools using in excess of 30 gig... well, not "not uncommon", it always is, and I have several C++ projects open at once, so each one is using a load on its own. I've had to set a shell job to sit in a loop sleeping and then killing it repeatedly before, when my system is struggling for memory and I need the least important thing to die.

I think one of the issues for me is - without knowing how it works beyond probably a language server - I feel like it's probably trying to work like a compiler and understand the whole project. Even the python extension often underlines things that are fine and fails to underline things that aren't, so gut feel is, it just won't, it's asking too much. When C++ project builds are much more complicated it can't possibly know all the flags and include directories, dependencies, that are needed to build what I'm working on right now. And that's completely fine. I don't know if there's a setting for this, but I'd personally like it to run in much more of a stripped-back version. I don't expect it to be able to find semantic errors and add red squiggly underlines, for that I'll build and control-click on the error message, which to be honest I need in full, with a backtrace of template instantiations, to diagnose the problem anyway. I'd like to be able to hit F4 to change header to source, something that sometimes takes a minute to run and then gets totally the wrong file. If it can find some basic typos and issues between one source file and one or two of the headers it includes directly, just in the scope that it cans see in the document I'm currently typing (e.g. using -> when it's an object on the stack that's not a pointer) then great, otherwise it appears to be using a massive amount of system resources by default trying to provide all the insights a compiler could except without knowing how my compiler is set up and failing in the process. I'd prefer more textual stuff like being able to refactor a method from a header into a source file than for it to attempt to catch subtle issues and parse an entire project. And I guess for it maybe to set a limit on how hard it's gonna work trying before it give up, as that's better than crashing my system or spinning up the fans massively, cause I see several mentions of others' experiencing issues like this, so I think it makes sense to have a hard limit by default.

[sean-mcmanus]

@stellarpower It sounds like you're hitting a bug. Is 30 GB with a single cpptools process or all of the cpptools-srv included? We can probably configure like the build does if you supply a compile_commands.json or use CMake Tools or Makefile Tools as the configurationProvider.

[stellarpower]

Afraid I'm not sure. I never trust the output the Linux kernel gives, it's currently saying code is using a terabyte of virtual when there is only a tenth of that physically installed and barely any swap so honestly I never know where to look to get any reasonable idea. I'm pretty sure I've seen both. Htoonshoukd be set up to collapse threads under the same process but I still usually see duplicates, especially with many applications now using a multiprocess rather than a multi-threaded architecture.

I haven't configured it myself before, it usually just starts in the background. I guess I might be able to generate compile commands as JSON. Often I am using several different build processes in the same window though, I usually just build through the shell.