Skip to content

Go to Symbol in File is slow #4934

Closed
Closed
Go to Symbol in File is slow#4934
Labels
Feature: Symbol SearchLanguage Servicebuginvestigate: reproThis issue's repro steps needs to be investigated/confirmedperformance

Description

@HackerBaloo
Björn Carlsson (HackerBaloo)
opened on Feb 7, 2020

attached.zip
Type: LanguageService
What I run

  • OS and Version: Ubuntu 18.04
  • C/C++ Extension Version: 0.26.3
  • VS Code Version: 1.41.1
    Commit: 26076a4de974ead31f97692a0d32f90d735645c0
    Date: 2019-12-18T15:04:31.999Z
    Electron: 6.1.5
    Chrome: 76.0.3809.146
    Node.js: 12.4.0
    V8: 7.6.303.31-electron.0
    OS: Linux x64 4.15.0-76-generic
    The behavior is still there if I disable all extensions except C/C++

To Reproduce
I have a Workspace with 87000 files, 12500 of these are cpp/h files

  1. I have my Workspace open
  2. Ctrl+P to open SemanticModule.cpp (for example, I have the same issue with all files)
  3. I use my hotkey for: "Go to Symbol in File" aka "workbench.action.gotoSymbol"
  4. It takes 56 seconds to show the list of symbols (on my CoreI9 with 64 GB of memory)
  5. next time it shows up directly
  6. add an empty row in the file
  7. goto point 3 above

Expected behavior
It shouldn't take much longer to find the symbols in a file than it takes to compile the file.

Additional context
I tried turning on logging like this, but didn't get any output.
("C_Cpp.loggingLevel": "Debug" in settings.json).
But I'm very willing to provide more information.

Activity

  1. HackerBaloo commented on Feb 7, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 7, 2020
    Author

    Well that funny, I think I found a workaround just moments after submitting this issue, I had both a compile_commands.json and as fallback (I thought) I also have a rather wide includePath. If I removed the includePath it just take a couple of seconds.

  2. sean-mcmanus commented on Feb 7, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 7, 2020
    Contributor

    The includePath might be copied over to the browse.path setting, which is used to generate global symbols and a filename cache -- the initial one-time slowness could be caused by the generation of these caches -- a similar issue was reported at #1127 .

    I don't understand steps 6-7...are you saying the slowness repeats after those steps? This is a one-time delay, right?

  3. Sean McManus (sean-mcmanus)
    added
    bug
    duplicate
    Language Service
    more info neededThe issue report is not actionable in its current state
    performance
    Feature: Symbol Search
    on Feb 7, 2020

  4. HackerBaloo commented on Feb 7, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 7, 2020
    Author

    Yes it the slowness was repeated after every time I added or removed an empty row in the file and then ran the command again.

  5. Sean McManus (sean-mcmanus)
    removed
    duplicate
    more info neededThe issue report is not actionable in its current state
    on Feb 7, 2020

  6. sean-mcmanus commented on Feb 7, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 7, 2020
    Contributor

    Sounds like you're hitting a different issue from the other one. Did you see logging in the C/C++ pane: see https://code.visualstudio.com/docs/cpp/enable-logging-cpp ? You can also run C/C++: Log Diagnostics to get info on the IntelliSense settings used by the current translation unit.

    The issue didn't repro for me with just that 1 file. It's possible the processing is stuck due to IntelliSense blocking our input queue or tag parsing.

  7. HackerBaloo commented on Feb 8, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 8, 2020 via email
    Author

  8. HackerBaloo commented on Feb 8, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 8, 2020
    Author

    output.zip
    Well unfortunately, the log output doesnt tell the true story.

    When I add an empty row and opens Go to Symbols in file, the log shows this;

    sending 1 changes to server
cpptools/cpptools_finishUpdateSquiggles
Error squiggle count: 0
Update IntelliSense time (sec): 0.742
Database safe to open

    but the progressbar continues 50 more seconds until the content is shown-

  9. HackerBaloo commented on Feb 8, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 8, 2020
    Author

    And today when I test again my workaround to remove the includePath setting doesn help anymore,

  10. 5 remaining items

  11. HackerBaloo commented on Feb 11, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 11, 2020 via email
    Author

  12. HackerBaloo commented on Feb 11, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 11, 2020 via email
    Author

  13. HackerBaloo commented on Feb 11, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 11, 2020 via email
    Author

  14. sean-mcmanus commented on Feb 11, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 11, 2020
    Contributor

    Log Diagnostics shows "no translation unit" -- that means no IntelliSense is running. Do you have the source file active?

    If SwitchHeaderSource (or Go to Def or Find All Refs) doesn't work until you open a file, it means the file wasn't parsed, probably because it wasn't included from the includePath (or browse.path) setting. You can use files.exclude to exclude folders you don't need to make the database smaller.

    You can also set C_Cpp.loggingLevel to view diagnostic info in the C/C++ pane on what files are getting "tag parsed".

    You could file a new issue if you want.

  15. sean-mcmanus commented on Feb 11, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 11, 2020
    Contributor

    Also, if you're using compile_commands.json, it will try to get includePaths from that, but you may need to set your browse.path setting to include all the folders that you want to be parsed for global symbols (see #1715 ).

  16. HackerBaloo commented on Feb 12, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 12, 2020 via email
    Author

  17. HackerBaloo commented on Feb 12, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 12, 2020 via email
    Author

  18. sean-mcmanus commented on Feb 12, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 12, 2020
    Contributor

    The include shown from C/C++: Log Diagnostics are from compile_commands.json and not the same used for workspace symbol searching/parsing (from browse.path), e.g. I don't see the develop/server folder under the browse.path. Can you add those folders or was that the cause of the large database?

    If you set C_Cpp.loggingLevel to "Debug" you can see more diagnostics on the browse.path affect.

  19. HackerBaloo commented on Feb 13, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 13, 2020 via email
    Author

  20. sean-mcmanus commented on Feb 13, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 13, 2020
    Contributor

    Ah, okay.

    Your usage of "browse.path" appears incorrect -- it should be

    "browse": {
   "path": [
     ]
}

    i.e. you can add the "path" property next to your existing limitSymbolsToIncludedHeaders property.

    Have you been able to see the "C/C++" debug logging yet to see what files are getting "tag" parsed? That info can help diagose issues with an incorect browse.path.

    80 MB seems too small if you have a really large workspace, but the 3.9 GB might lead to performance issues. You might want to use "${workspaceFolder}/*" (non recursive) and "${workspaceFolder}/subfolder" to specify fewer directories for symbols or add folders to files.exclude.

  21. HackerBaloo commented on Feb 14, 2020

    @HackerBaloo
    Björn Carlsson (HackerBaloo)
    on Feb 14, 2020
    Author

    latest.zip

    I have now adjusted and trimmed my browsing settings. and the result is a 346 MB DB. Attached also the output when all files are tag parsed after a reset of the DB.
    But for some reason when I now execute "Go to Symbols in File" the progress never seems to stop.
    And then I tested a restart of Code, and now it works fine. Case closed I guess.

  22. sean-mcmanus commented on Feb 14, 2020

    @sean-mcmanus
    Sean McManus (sean-mcmanus)
    on Feb 14, 2020
    Contributor

    Go to Symbol in File could get stuck if our parsing queue is backed up with work. Let us know if you find a consistent repro.

  23. Bob Brown (bobbrow)
    closed this as completedon Feb 20, 2020
  24. github-actions
    locked and limited conversation to collaborators on Oct 8, 2020

  25. fearthecowboy commented on Feb 13, 2024

    @fearthecowboy
    Garrett Serack (fearthecowboy)
    on Feb 13, 2024
    Contributor

    A significant update to Go To Symbol has been published in the insiders build - see #11557

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Feature: Symbol SearchLanguage Servicebuginvestigate: reproThis issue's repro steps needs to be investigated/confirmedperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions