Repository navigation
ctrl-clicking #include "<filename>" should be instant #8217
Description
Issue Type: Bug
the default location for a #include with double-quotes is relative to the file containing that line. if that file exists, the double-click operation should be instantaneous. however, in my large project (thousands of files), sometimes opening an include in the same directory makes the blue progress spinner spin for a while, indicating that it's doing some kind of unnecessary search.
Extension version: 1.6.0
VS Code version: Code 1.60.2 (7f6ab5485bbc008386c4386d08766667e155244e, 2021-09-22T12:00:31.514Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No
Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2
Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2
Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2
System Info
| Item | Value |
|---|---|
| CPUs | Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904) |
| GPU Status | 2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled |
| Load (avg) | undefined |
| Memory (System) | 47.66GB (11.84GB free) |
| Process Argv | --crash-reporter-id 70645636-42ae-4864-b371-1810b42a2956 |
| Screen Reader | no |
| VM | 0% |
| Item | Value |
|---|---|
| Remote | WSL: CentOS7 |
| OS | Linux x64 5.10.16.3-microsoft-standard-WSL2 |
| CPUs | Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904) |
| Memory (System) | 37.35GB (1.74GB free) |
| VM | 0% |
| Item | Value |
|---|---|
| Remote | WSL: CentOS7 |
| OS | Linux x64 5.10.16.3-microsoft-standard-WSL2 |
| CPUs | Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904) |
| Memory (System) | 37.35GB (1.74GB free) |
| VM | 0% |
| Item | Value |
|---|---|
| Remote | WSL: CentOS7 |
| OS | Linux x64 5.10.16.3-microsoft-standard-WSL2 |
| CPUs | Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904) |
| Memory (System) | 37.35GB (1.74GB free) |
| VM | 0% |
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
vscorecescf:30358481
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
vsccppwtct:30364498
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30371810
dockerwalkthru:30370836
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedc:30364665
pythonvspyt187:30373474
pydsgst2:30361792
vsqsis200:30374795
Activity
sean-mcmanus commentedon Oct 5, 2021
I don't believe it does a search (from looking at the code). The goto request is most likely blocked by a previous request, such as the hover. Does the issue repro if you put your mouse cursor on the
#include, wait for CPU usage to drop to 0, and then use the F12 key?Spongman commentedon Oct 5, 2021
yeah, it looks like it's blocked by the hover.
the issue is the same, though. either click/wait, or wait/click, the wait is still there...
sean-mcmanus commentedon Oct 5, 2021
You mean it's delayed whenever there's a hover? If you set C_Cpp.loggingLevel to "Debug" you can see either textDocument/hover or definition messages to see what it's processing (the logging after the result becomes available could be helpfult too). Our main thread is most likely stuck on something, either the hover or a previous documentHighlight and/or IntelliSense update request -- if you attach a debugger to cpptools (https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv) and look for a thread that has a send_message call, that would indicate that those threads are blocked by an IntelliSense message. We'd need more info to determine if this is "by design" or something that could be improved.
Spongman commentedon Oct 5, 2021
Well, being "by design" doesn't preclude improvement. Maybe in your small test projects it doesn't seem like an issue. But in my daily use it's definitely a usability issue, whatever the cause.
sean-mcmanus commentedon Oct 5, 2021
Yeah, we could potentially move the processing that is blocking the main input thread to a different thread, but we'd need more info on exactly what processing is blocking the go to definition for you, otherwise, we might not fix the issue you're hitting. Are you able to get more info on what processing is blocking the Go to Definition?
bobbrow commentedon Oct 5, 2021
This is something that should be improved by our "Unification with VS" effort.
github-actions commentedon Dec 5, 2021
This issue has been closed automatically because it needs more information and has not had recent activity.
bobbrow commentedon Dec 6, 2021
This shouldn't have been closed for 'more info needed' reasons. We understand the issue, but we expect that it will be resolved as part of #5775. Thus, this is actually a duplicate.