search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.52k stars 1.55k forks source link

Excessive CPU usage with https://github.com/dotnet/runtime #7115

Open sean-mcmanus opened 3 years ago

sean-mcmanus commented 3 years ago

I'm experiencing this in my linux development VM for https://github.com/dotnet/runtime, running a VS Code client on Windows connected to the linux host (so cpptools runs on the linux host along with some node processes, while the UI runs outside of the linux host). Has any testing happened with that repo for this issue? It does seem to be much worse during builds, which is confusing because I got the impression that vscode takes gitignore into account for these things like it does for project-wide search and build artifact directories are ignored.

When I checked in and opened top, cpptools' cpu time total was around 65 hours, with xorg and konsole at 23 and 21 hours and node (probably the cpptools parent?) at 19. cpptools also was using about half a gig of memory (2.4g virtual).

Originally posted by @kg in https://github.com/microsoft/vscode-cpptools/issues/5574#issuecomment-791321351

plaip commented 3 years ago

@sean-mcmanus - I have the same problem, please tell how can I help you?

sean-mcmanus commented 3 years ago

@plaip You have the same problem in the same repo or in a different one?

sofianeDegoui commented 3 years ago

I have the same problem. Cpptools takes 99% of cpu. I use vscode for a another project image

My laptop is on Ubuntu 20.04 LTS.

sean-mcmanus commented 3 years ago

@sofianeDegoui Excessive CPU usage is a symptom with many potential causes (i.e. we can't determine if it's the "same" without more info). Can you file a new issue with more repro details, and a call stack (https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv) of the process when it's using the CPU and/or perf data (https://github.com/microsoft/vscode-cpptools/wiki/Troubleshooting-Performance-Issues).

sofianeDegoui commented 3 years ago

Thanks @sean-mcmanus

In my case is easy to reproduce the bug, just i use vscode to write code and after few minutes, it takes 99% of the cpu.

The perf data: image

The call stack, i stopped gdb when the cpptools takes 99% of cpu: libc.so.6!GI_libc_read(size_t nbytes, void * buf, int fd) (/build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/read.c:26) libc.so.6!GI_libc_read(int fd, void buf, size_t nbytes) (/build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/read.c:24) libc.so.6!_IO_new_file_underflow(FILE fp) (/build/glibc-eX1tMB/glibc-2.31/libio/libioP.h:948) libc.so.6!GIIO_default_uflow(FILE fp) (/build/glibc-eX1tMB/glibc-2.31/libio/libioP.h:948) libc.so.6!_IO_getc(FILE fp) (/build/glibc-eX1tMB/glibc-2.31/libio/getc.c:38) __gnu_cxx::stdio_sync_filebuf<char, std::char_traits >::underflow() (Unknown Source:0) std::basic_istream<char, std::char_traits >& std::getline<char, std::char_traits, std::allocator >(std::basic_istream<char, std::char_traits >&, std::__cxx11::basic_string<char, std::char_traits, std::allocator >&, char) (Unknown Source:0) vscode::message_handler::main_loop() (Unknown Source:0) main (Unknown Source:0)

sean-mcmanus commented 3 years ago

@sofianeDegoui Are you able to expand the + in the perf viewer? From what I see, it looks like normal usage, probably from tag parsing or some other directory iteration. You could possibly add folders to files.exclude or C_Cpp.files.exclude to do less parsing. If you set C_Cpp.loggingLevel to "Debug" you may be able to see more info in the C/C++ logging pane. The call stack is from the main thread which isn't doing any work -- are you able to get the call stack from another thread that is doing work?

sean-mcmanus commented 3 years ago

@sofianeDegoui This might be the same issue as https://github.com/microsoft/vscode-cpptools/issues/7394 . Is the issue fixed if you downgrade to 1.2.2?

sean-mcmanus commented 3 years ago

@sofianeDegoui You may want to check if you see "Folder: / will be indexed" in your C/C++ logging if you're using compile_commands.json, because there's a potential regression in 1.3.0 that could cause that.