cpptools high cpu utilization

[mdchitale]

Hi,

I am using vscode on ubuntu 18.04. Following are the details:
Version: 1.57.1
Commit: 507ce72a4466fbb27b715c3722558bb15afa9f48
Date: 2021-06-17T13:26:56.255Z
Electron: 12.0.7
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Linux x64 5.4.0-77-generic

I have a workspace which contains linux kernel source and when I open this workspace, I see cpptools process taking almost 100% cpu all the time. The intellisense version is v1.5.0-insiders3.

Has anyone faced a similar issue?

I dont think its related to workspace as I see same issue with another workspace too. Also IIRC vscode 1.54 did not have this issue.

Thanks,
Mayuresh.

[sean-mcmanus]

If you use any paths that start with /I or /D you may be hitting an issue related to #7701 .

[mdchitale]

No. I dont have any paths that start with /I or /D.

[sean-mcmanus]

Can you enable debug logging to see what is going on (https://code.visualstudio.com/docs/cpp/enable-logging-cpp)? If you don't get any output, can you temporarily set the logging to the hidden value of "7"?

[mdchitale]

PFA the output log from the workspace. When I saved the output 'Parsing files' was almost 35 % complete and it appeared to be stuck with the following messages in the output:

Database safe to open
tag parsing file: /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/include/asic_reg/mp/mp_9_0_offset.h
tag parsing file: /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/amdgpu/vega10_ih.h
tag parsing file: /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
tag parsing file: /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_2_3_offset.h
tag parsing file: /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_2_3_sh_mask.h
Database safe to open

Also, can I skip the following folders from indexing?

Folder: /usr/include/ will be indexed
Folder: /usr/lib/gcc/x86_64-linux-gnu/7/include/ will be indexed
Folder: /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/ will be indexed
Folder: /usr/local/include/ will be indexed
log.txt

[sean-mcmanus]

The logging indicates that the processing is from tag parsing of your workspace files. When you says it appears to be "stuck" do you mean CPU usage is still high and no other logging appears when you do stuff like hover? If so, it seems like our parser is stuck in an infinite loop, possibly when parsing file /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/include/asic_reg/mmhub/mmhub_9_4_1_sh_mask.h or some file afterwards. Are you able to open /home/mchitale/riscv/kernels/latest/linux/drivers/gpu/drm/amd/include/asic_reg/mmhub/ and see if the same issue repros, and/or isolate which file it's getting stuck parsing?

You can add /usr/include etc. paths to C_Cpp.files.exclude to prevent them from being indexed, however it doesn't seem like those folders are causing your CPU usage issue.

[mdchitale]

Yes, that is correct. No logs appear but the cpu utlization continues to be high. I checked this directory: mmhub and it has 155605 lines of code almost entirely consisting of C macros for register definitions. Is that the problem?

[sean-mcmanus]

This is a duplicate of #6454 (tracked in VS by https://developercommunity.visualstudio.com/t/updating-cc-intellisense-and-browsing-information-1/1263948 ) -- I pinged the VS C++ team about it to see if the priority can be increased, i.e. the code is doing O(N^2) processing for files with a lot #defines, so your 100k+ line file is processed too slowly.

[mdchitale]

Yikes! Thanks for the information though.
Do you know if this issue will hit other similar extensions as well? Just yesterday I installed the cscope extension but I havent used it much till now.

[sean-mcmanus]

I don't know if other extensions would hit this. They'd have to have some other O(N^2) algorithm.

One potential workaround is to use setting:

    "C_Cpp.files.exclude": {
        "**/.vscode": true,
        "**/asic_reg": true
    }

and add whatever folders to that which have similar large #define files. The effect is you won't get global symbols for files in those folders, but that may not be important.

[djairao]

As a curiosity question, how does vs-code's IntelliSense parse files? Does it run a locally installed compiler or does it have a binary that it runs?

I am curious because the parsing is pretty slow on a RHEL supercomputing cluster. I can reproduce the slowdown on another CentOS cluster. So I know there is something about the way they are set up that causes this slowdown (I have tried on 2 local Linux machines and it runs fine). I have spent hours trying to figure out the issue (don't know if it is an I/O issue or what). I know I can dig through the source code on git hub, but I thought I would ask (just to save myself some more time trolling through the source code). There isn't much in the logs (in debug mode) to troubleshoot performance issues.

[sean-mcmanus]

@djairao The issue is caused by our "tag parser" in cpptools (which does a "fuzzy" parse of global symbols and stores info in the database) and not the "IntelliSense" parser in cpptools-srv (which just a "real" parse of the current TU). Neither runs an installed compiler. The parsing code is closed source. The slowness you're experiencing may be different from the original issue (which isn't really with "parsing" but code related to updating the database with the parsed results). It only runs on a single core, but even if more cores were added the database access might be a bottleneck anyway.