microsoft / microsoft/vscode-cpptools
Performance & functionality with real world mid-large C++ codebases
まだ誰も着手していません。
- 主要言語
- TypeScript
- スター
- 6.2k
- フォーク
- 1.7k
- 平均マージ
- 14時間 46分
- マージ済み PR(30日)
- 61
説明
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?
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
hoverProvider.ts と languageClient.sendRequest 周辺のプロファイリング経路から始めて、遅延が拡張機能にあるのか、非公開の language server にあるのかを特定します。再現可能なボトルネックと、担当するコンポーネントを明確に特定できれば完了としますが、この issue には具体的な失敗ケースも対象となる変更もありません。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- cpp, typescript
- 領域
- performance
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100