Improve performance with 10000+ compile commands entries #10029
Assignees
Labels
Feature: Compile Commands
fixed
Check the Milestone for the release in which the fix is or will be available.
Language Service
performance
Milestone
Comments
sean-mcmanus
added
Language Service
more info needed
|
Can you try with 1.13.2 (pre-release) -- we improved the performance in the scenario where there's a lot of compile command entries with the fix for #9882 . If it's still and issue after that, can you give more info on what is going on in the 5-10 min, either from the C/C++ logging with C_Cpp.loggingLevel set to "Debug" or by attaching a debugger to get a call stack? From the previous discussion, it sounds like it's just parsing the compile_commands.json file and not tag parsing the workspace, right? |
|
The Output with logging level debug looks like this with version Getting the C++ compiler properties gets posted very often. So it seems to be the the issue in #9882. I'll give the pre release version a try. |
|
I'll installed the pre release version and the result does not change. Here is a part of the log Part of the Log of Version 1.13.2
There is also no change in the timing. It still takes 5 to 10 min until intellisense is rdy. |
|
If i want to test just tag parsing, is it enough to remove the |
|
Also this sounds related. microsoft/vscode-cmake-tools#2586 |
|
The CMake Tools issue would only apply if you're using CMake Tools instead of compileCommands to configure. I don't know why you wouldn't be seeing a performance improvement with 1.13.2. How many "Attempting to get defaults from C++ compiler in "compilerPath" property: '/usr/bin/clang'" do you get a second? Are you able to attach a debugger to get a call stack? It might just be slow to parse/process the json file. |
sean-mcmanus
added
investigate: repro
|
I'm not sure what you mean by "If i want to test just tag parsing, is it enough to remove the compile_commands.json file from the c_cpp_properties.json?". If you don't see tag parsing messages in the Debug logging then it's not an issue with tag parsing (from the logging I see so far it's not a tag parsing issue). |
Right i don't use CMake-Tools to configure. I only rely on the
Can you point me to a tutorial or some doc how to attach a debugger so i can provide a call stack ? I have never done this before
Currently my I made a rough measurement with a stopwatch today again :) When i start VSCode the last |
|
There's info on how to get a call stack at https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv . However, I think we have enough repro info so I don't think we need a call stack. |
sean-mcmanus
changed the title
sean-mcmanus
removed
the
investigate: repro
|
try to set |
sean-mcmanus
added
the
fixed
|
@hriekehof This should be fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.22.0 -- let us know if you still see performance issues. |
|
We're tracking additional performance improvements with #12825 . |
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
Feature Request
I work in a large multi project mono repo which is closed source. I have a large
compile_commands.jsonwhich is generated from thexcodebuildoutput and it's around 102MB with roughly 12000 entries. Myc_cpp_properties.jsonis quite simple:{ "configurations": [ { "name": "LargeCodebase", "includePath": [ "${workspaceFolder}/project1/**", "${workspaceFolder}/project2/**", "${workspaceFolder}/shared/**" ], "defines": [], "compilerPath": "/usr/bin/clang", "cStandard": "c11", "cppStandard": "c++14", "macFrameworkPath": [ "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks" ], "intelliSenseMode": "macos-clang-arm64", "compileCommands": "${workspaceFolder}/somewhere/compile_commands.json" } ], "version": 4 }When i open VSCode it takes around 5 - 10min until i have intellisense up and running. Switch header source, see the Outline view etc.
This is also the case if i just reopen the window and the
compile_commands.jsonhasn't changed at all. In #8647 i brought up the idea of aProgressBarthat you can see how long you still have to wait.But i was wondering why does it always need so long at startup when nothing has changed in the
compile_commands.jsonfile ?Is it possible to improve the startup time of the Code browsing service ?
The text was updated successfully, but these errors were encountered: