Performance & functionality with real world mid-large C++ codebases

Hello!

EDIT: Forget about it. I have just seen this https://github.com/microsoft/vscode-cpptools/blob/main/RuntimeLicenses/cpptools-srv-LICENSE.txt

No plans to make it public?

CONTEXT
Since we transitioned in my company from QtCreator to VSCode for C++ development in our WSL environment, I have faced a lot of complains in different areas regarding the overall status of it. We have mid-large-huge C++ codebases and that could arise different and undetected issues than toy projects or small ones.

A recurring complain is just that it's really slow. Hovering, finding references, go to definitions, debugging, indexing could take ages; sometimes they just did not work, sometimes it just crashed with the infamous Remote unexpected issue.

For now a lot of devs have been using clangd extension as replacement with a range of success; faced other issues but at least works generally better for the codebases.

MOTIVATION
I decided to give it a more in-depth look in my free time to help you if possible to identify where the problems are coming, get some numbers, profile the application and see where it could be improved. This is linked with this initiative affecting the CMakeTools extension also, which faces the same problem of poor performance with our codebases; a quick profiling gave us hints where to focus and how to.

Same applies here: I'm not a Typescript developer, but at least I hope to get more insights of the performance problems and overall experience.

CURRENT STATUS
Debugging the extension and enabling the Profiling to check why the InteliSensee takes so much time; the hovering / FindAll references &c.
However, it's not identifying any time-consuming function because they seem to be residing in other node_modules, so I got a cold shower in my expectations:

Naive example in hoverProvider.ts

        console.time("hover")
        let hoverResult: vscode.Hover;
        try {
            hoverResult = await this.client.languageClient.sendRequest(HoverRequest, params, token);
        } catch (e: any) {
            if (e instanceof ResponseError && (e.code === RequestCancelled || e.code === ServerCancelled)) {
                throw new vscode.CancellationError();
            }
            throw e;
        }
        if (token.isCancellationRequested) {
            throw new vscode.CancellationError();
        }
        console.timeEnd("hover")

So perhaps some of the complains I've receiving is not because the extension itself, but waiting for the response of other code modules. For this case, where is actually the code processing the request? If it's not the extension, I'm afraid we'll reach a dead end; I guess it's the Language Server cpp-srv the responsible one, but the code not public anywhere, right?

Start with hoverProvider.ts and the profiling path around languageClient.sendRequest to determine whether the delay is in the extension or the non-public language server. Done would require identifying a reproducible bottleneck and a clear component owner, but the issue provides no specific failing case or target change.