-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Improve compiler arg parsing performance #9882
Comments
Is clang itself using the CPU? (sounds like the answer is Yes -- did you have a suggestion on what we should do differently?). What amount of time is "takes forever"? The compiler defaults query should only be called during initialization (maybe other cases?), so you mean IntelliSense takes a long time to start initially? |
Okay, I see now -- multiple "Attempting to get defaults from C++ compiler " occur whenever a new file is opened (not sure why, might be a bug). My guess is you're actually hitting #9688 -- you can confirm that via attaching a debugger to the cpptools process and looking for "wordexp" on one of the call stacks. |
I'm not reproing the bug. The "Attempting to get defaults from C++ compiler" is fast and it only appears initially when processing the compile commands and not when opening new files (looks like it occurs repeatedly with a configuration provider). Do you have a .zshenv that could be invoked when calling wordexp? As reported in #9688 ? |
Fresh start with no open files (6 times "get defaults"):
Opening a file (1 more "get defaults"):
Reopening the same file (no more "get active")
For me is also very fast. |
Yeah, the "Attempting to get defaults from C++ compiler" logging is just misleading -- we have a cache that is used but the logging occurs regardless of whether the cache is used or not. Was there some other issue? The cache may not get used if a compiler args are different in a different compile commands entry though. |
It only happens on VSCode start. Doesn't matter the file that's open. I have a config file open so I don't get default Intellisense info in the log. More files in compile commands will increase slowness because every file, in compile commands file, gets a compiler defaults query. When trying my test repo the paths in the files must be fixed for your system. I had this problem where I still had my Windows paths in the compile commands files and trying it out on Mac showed no problems with querying defaults slowness. Once I fixed the paths the slowness showed. You'll have to bear with me with the other info. I'm new to Mac so it'll take awhile. |
Auto download C++ extension from store = 5 seconds between compiler query The bug is still there but the native extension speed mitigates it. There was also a problem with Intellisense not working with the Apple Silicon version and UE5. Changing to the non default config in the c_cpp_properties seems to have fixed that though. There is room to improve the speed though. The .5 second pause between compiler queries is still annoying and it'd get more annoying with more project files(compile command entries). Not sure if you want to close this or not. |
Seems UE5 doesn't like the Apple Silicon extension version when first creating projects. This could be my Mac configuration though. I'll need time to sort it out and test. |
Yeah, I fixed the paths in the repro project so they were all valid. I'll see if anyone else on our team is able to repro it. |
@boocs I wasn't able to repro this with your example (with paths updated). Also, the C/C++ Extension should be analyzing the command line and only querying the compiler again when arguments are present that differ from a previous query, and which are known to influence the results (or are unknown/undocumented). If you see multiple instances of The A custom configuration provider will take precedence over compile_commands.json. It looks like @lucasaf04 appears to be using a configuration provider. @boocs Could you provide logs from your repro? |
Are you testing on M1 Macs? Could be an issue with that particular machine. The M1 Mac user, of my extension, reported that installing the Apple Silicon verison of the cpptools extension helped his compiler query slow weirdness. I'm still working on an issue with the M1 Mac I was testing on so it might be awhile. |
Here's a video of the behavior on an M1 Mac with the Apple Silicon version of cpptools. As you can see, there is still a pause but it's still way faster than the other Mac extension version. Note: My cloud Mac provider installed Xcode 14 so I'm unable to use it properly. I'll need to find another cloud mac provider if you want any more testing done. unknown_2022.09.19-14.53_clip_1.mp4 |
Here's the non native version of your extension on an M1 Mac for comparison. unknown_2022.09.19-14.33_clip_1_Trim.mp4 |
Thanks @boocs . I see the problem now. The delay seems to be due to the compounded overhead of individually processing the hundreds of arguments in the RSP file, multiplied by each of the compile_commands entries that reference it. The delay doesn't appear to be due to any one very slow call, but rather the compound overhead of so many calls to parse an argument. (There may be some culprit that is taking many milliseconds longer on M1 Mac, but I'll need to dig further to identify it). We could potentially improve this specific scenario by temporarily caching the results of resolved RSP files, so this happens only once per RSP file in the configuration. But, if a different RSP file were used per file, that wouldn't help. A better solution would seem to be for us to refactor our arg parsing code path to be more performant in general. We can use this issue to track doing that. |
Yeah, I see <0.5 second of a delay on Mac M1 now (per each "Attempting to get defaults"). |
Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.2 . With your repro project it went from 5 seconds to instantaneous -- if you're still seeing performance issues with your other projects we may have to investigate further improvements (so a different repro might help in that case). |
I'm unable to test because I only rented the Mac to test my extension. I do plan to rent a Mac and test again in the near future. I'm not sure what best practice is on when I should close this issue? |
We'll close the issue ourselves when we ship the final 1.13.x. And if there's still and issue you could re-open it later or create a new issue. |
Environment
Intellisense works. Intellisense takes a long time to work because this takes forever:
Doesn't matter if you remove the "compilerPath" setting and let cpptools pull the compiler from compiler commands.
The example repo is a single workspace that has the same problem.
The original project is a multi workspace Unreal Engine 5 project.
Tested with clang 13.1.6 and clang 14.0.0
Removing 200 includes. Still slow.
Removing 250 includes. A little better.
Removing 275 includes. Decent.
The "includePath" setting is commented out on purpose. It was only there for my testing.
https://github.com/boocs/TestFps
Bug Summary and Steps to Reproduce
Bug Summary:
Slow querying of compiler defaults with compile commands and lots of includes
Steps to reproduce:
Expected behavior
Fast querying of compiler defaults
The text was updated successfully, but these errors were encountered: