-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Processing a large compile_commands.json takes too long #12825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@akbyrd Did you repro this with 1.22.8 too? That has some potential fixes. It appears to be stuck from |
Yea, looks like the insiders version I have is 1.22.8 and I was able to repro there. The logging is a little different though. I see a continuous stream of
It doesn't seem stalled, it just seems like it's doing a boatload of work before enabling LSP operations.
|
77,727 in one workspace with just the engine Big numbers, and I'll be the first to complain about it, but it is what it is. I can't really pare it down since I'm poking at foundational bits that everything uses. I think the important requirement here is that Intellisense and LSP operations for the current file can't depend on work being performed in all files, only its actual dependencies. That might still be a large number of files, and that's ok, as long as it's not artificially gated by everything. I don't think this was always an issue. I've been working in this codebase for a few years and I think the extension would fallback to the tag parser if Intellisense was still trying to catch up. I vaguely recall that I'd have basic operations that weren't entirely accurate for a while in a new workspace, then it would catch up after a while. Currently I get no operations at all, everything stalls with a loading bar until the init phase is complete.
I haven't seen it finish yet. I'll let it go overnight tonight to see if it completes. How can I see the progress? Is there a log file with progress and timestamps so I can estimate the completion time if it doesn't finish? |
After letting it sit for a while it did get past initializing. Without timestamps I can't say how long it took, but more than 1 hour and less than 2.75 hours. I set the logging to "7" instead of "Debug" which I saw you mention elsewhere. I see about 100,000
then a few
then all the pending LSP operations finally begin to process
then some more processing
|
No, it was my retail install that I let run (1.21.6). Is there any other helpful data I can gather? |
@akbyrd If you can try with 1.22.8 (which we're planning to release soon as 1.22.9 non-pre-release) and let us know if (how much) it is faster that would help. But otherwise, I think we have enough info. |
I let 1.22.8 grind away on the 108k workspace and it took around 2.75 hours (+/- 30 minutes). AMD EPYC 7R32 with 32 threads and 128 GB of memory available. |
@akbyrd Okay, sounds like "no improvement". |
@akbyrd Also, FYI, the Visual Studio 2022 product has specific optimizations and functionality for Unreal Engine that don't exist in VS Code, so you may want to consider that instead. |
Thanks for the tip. I'm using that as a fallback for the moment. But the goal is to stick when vscode as vs is much too slow for daily use. I noticed it does some initial parsing for headers for the first minute or so and then Intellisense operations work so it doesn't seem to get blocked up on the initial. But the build tool for Unreal produces some sort of Intellisense data in advance, but I haven't looked into exactly what that data is yet. So it might be pre-populating some of the data that vscode has to figure out for itself. |
Environment
Bug Summary and Steps to Reproduce
Bug Summary: The extension gets stuck initializing Intellisense more or less permanently when loading a compilation database with a large number of file entries. The extension is unusable while this occurs. It's a single threaded process that appears to process every file in the compilation database before enabling any LSP features for currently opened files.
Steps to reproduce:
a. Sorry, I know this is a pain for a repro. There's a small, self-contained partial repro I can't share publicly if there's a private channel available.
GenerateProjectFiles.bat -VSCode
AssertionMacroTests.cpp
)#include
statementExpected behavior:
When not using compile commands the tag parser fallback behaves correctly. It will immediately parse the current open file. Similarly, clangd handles the current file before doing background indexing.
It's also possible to observe the bad behavior with just the .vscode directory and not the entire engine. When the actual code files are missing the
C/C++ Configuration Warnings
output will be spammed with errors like this:While this is occurring, Intellisense is in the "initializing" state indicating that it is processing every single file in the database before the init completes and LSP operations in the current file begin to function.
Configuration and Logs
I don't think I can get
C/C++: Log Diagnostics
. The command doesn't do anything. Looks like it's an LSP request? And since the LSP is essentially stalled it's not returning a response.Other Extensions
I've repro'd on Insiders with no other extensions.
Additional context
No response
The text was updated successfully, but these errors were encountered: