Workspace Parsing Incredibly Slow (10s per file)

[mbrittsess]

Environment

• OS and Version: Windows 11, 10.0.26200
• VS Code Version: 1.135.0
• C/C++ Extension Version: v1.33.8
• If using SSH remote, specify OS of remote machine: Ubuntu-22.04 running on WSL1

Bug Summary and Steps to Reproduce

Bug Summary:

The "Parsing Workspace" process runs incredibly, unacceptably slowly. I have timed it: it now takes nearly exactly 10 seconds to parse each file. For a project with thousands of files, this makes intellisense virtually unusable.

In task manager I see one cpptools process, one cpptools-srv process, and eight cpptools-srv2 processes, all of which are sitting at 0% or 0.1% CPU usage and between 6.1 MB and 68.5 MB of memory usage.

The most noticeable symptom is that "Go to definition" is now only capable of finding function declarations, not their actual definitions.

A separate issue which started appearing at the same time and may be related: attempting to use VSCode to merely search for text in files takes noticeably longer than it used to; searches which used to take 5 seconds now take closer to 20 seconds.

It started after...

This started yesterday, or maybe the day before. I had opened another project and installed the clangd extension. When I went back to working on my main project, both it and ms-vscode.cpptools were both still active and fighting, so I disabled the clangd extension (I have since uninstalled it as part of an attempt to fix this bug). It was some time after that that I started having this problem. It could be a coincidence, as VSCode releases a new update every few days and one may have coincided with this change.

Steps to reproduce:

1. Navigate to Windows folder containing a project.
2. Open the folder in cmd.exe
3. Start a WSL session
4. Run code <name of project>.code-workspace
5. Wait for VSCode to open and start trying to parse the workspace
6. Check the "C/C++ Tag Parser Status" entry in the status bar. Timing between when it shows "Parsing Open Files | Parsing files (n of 2766)" and "Parsing Open Files | Parsing files (n+1 of 2766)" is nearly exactly 10.0 seconds after multiple timing tests.

Expected behavior:

The time to parse 2766 files should be no more than 30-60 seconds total (as was experienced previously), not several hours (as it is now expected to take).

Failed attempts to solve...

I have attempted the following things to rectify the issue without success:

• Uninstalling the clangd extension from both the WSL host and the local, Windows version of VScode, rather than merely disabling it
• Uninstalling and then reinstalling ms-vscode.cpptools
• Restarting PC

Configuration and Logs

Our project has multiple workspaces, folders, and `c_cpp_properties.json` files. I have included one, with the contents of `includePath` redacted, as an example:


{
    "configurations": [
        {
            "name": "Production",
            "includePath": [
                "includePaths is redacted for IP reasons",
                "But the following two should be representative of the type of path used:",
                "${workspaceFolder:Firmware}/Contoso/Inc",
                "${workspaceFolder:Core}/Contoso/Inc/firmware"
            ],
            "defines": [
                "STM32G030xx",
                "USE_FULL_LL_DRIVER",
                "__STATIC=static",
                "__CONST=const",
                "BUILD_NUMBER=0"
            ],
            "compilerPath": "/usr/bin/clang-15",
            "compilerArgs": [
                "--target=arm-arm-none-eabi",
                "-mcpu=cortex-m0plus",
                "-isystem",
                "${workspaceFolder:Top Level}/Understand/ARMCLANG/include",
                "-fshort-enums",
                "-Werror=pointer-arith",
                "-Werror=implicit-function-declaration"
            ],
            "cStandard": "c99",
            "cppStandard": "c++17",
            "intelliSenseMode": "linux-clang-arm"
        },
        {
            "name": "Testing",
            "includePath": [
                "includePaths is redacted for IP reasons",
                "But the following two should be representative of the type of path used:",
                "${workspaceFolder:Firmware}/Contoso/Inc",
                "${workspaceFolder:Core}/Contoso/Inc/firmware"
            ],
            "defines": [
                "STM32G030xx",
                "USE_FULL_LL_DRIVER",
                "__STATIC=",
                "__CONST=",
                "BUILD_NUMBER=23495832",
                "FW_VERSION_MAJOR=0xA5",
                "FW_VERSION_MINOR=0xCD",
                "UNIT_TESTS"
            ],
            "compilerPath": "/usr/bin/clang-15",
            "cStandard": "c99",
            "cppStandard": "c++17",
            "intelliSenseMode": "linux-clang-x64"
        }
    ],
    "version": 4
}

Other Extensions

No response

Additional context

No response

[sean-mcmanus]

Matthew B Sessions (@mbrittsess) We have not seen this behavior yet. Does it also repro with 1.34.0 pre-release (which has a bunch of fixes). Can you downgrade to 1.32.2 of the C/C++ extension as a workaround?

Could this be caused by some virus scanning software? Are you able to get more repro details such as a call stack or perf trace: https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv or https://github.com/microsoft/vscode-cpptools/wiki/Troubleshooting-Performance-Issues

Your WSL files are located inside of WSL and not Windows, right? There might be a performance hit if you're accessing Windows files from WSL. Our extension runs on Linux in WSL.