Skip to content

Discovering Files over sshfs is too slow #1737

Description

@aabuelenin

Similarly to this Atom bug, cpptools discovering files is too slow when the files are hosted on nfs. Discovering 20k files takes about a minute, during that time the db icon will be present and sometimes the hotflame icon will be visible too. Intellisense is laggy or completely unusable during that time.
atom/atom#1766

I tested vscode with cpptools on Windows and on Linux without sshfs and it's super fast, when I start vscode it takes just a few seconds for the db icon to disappear.

I thought the language server in cpptools is a c++ application, why it's taking that long to discover files?

Activity

  1. aabuelenin commented on Mar 25, 2018

    @aabuelenin
    Author

    Set log level to 6
    -There's 6 log files 3 of them are empty, the process was forked many times (more than 6)
    -There's a size limit on the log file, so I'm not sure what the language server is doing after the limit is reached.
    -"Unable to determine real path of FILE_PATH. Error = 2" is being logged so many times
    FILE_PATH usually is a random folder in my workspace concatenated to a header file, seems cpptools is trying to fuzz the location of header files.

    Other than that I can see any other errors.

    My config looks like:
    {
    "name": "Linux",
    "compileCommands": "${workspaceFolder}/compile_commands.json",
    "intelliSenseMode": "clang-x64",
    "browse": {
    "path": [
    "${workspaceFolder}/d1",
    "${workspaceFolder}/d2",
    "${workspaceFolder}/d3/src/c++",
    "${workspaceFolder}/d4",
    "${workspaceFolder}/d5",
    "${workspaceFolder}/d6",
    "${workspaceFolder}/d7"
    ],
    "limitSymbolsToIncludedHeaders": true,
    "databaseFilename": ""
    },
    "cStandard": "c11",
    "cppStandard": "c++11",
    "compilerPath": "PATH_TO_G++"
    }

  2. bobbrow commented on Mar 26, 2018

    @bobbrow
    Contributor

    It is not fuzzing header files. It is attempting to find them. The compiler looks through your includePath to resolve #include directives. We should probably silence the real path logging for this case though.

  3. aabuelenin commented on Apr 2, 2018

    @aabuelenin
    Author

    Bob Brown (@bobbrow) makes sense, but why it's too slow? Cpptools' language server isn't nodejs app, correct?

  4. sean-mcmanus commented on Apr 2, 2018

    @sean-mcmanus
    Contributor

    Just because the code is written in C++ instead of node.js won't make it fast if the underlying calls to the OS and file and networking systems are slow (e.g. nftw on Linux). I don't think we've tested with sshfs so it could also be a bug. Are there symbols/files missing after the discovering/parsing is done?

  5. aabuelenin commented on Apr 3, 2018

    @aabuelenin
    Author

    I didn't expect it to be faster than the OS calls, I was just thinking that the extreme slowness might be related somehow to the bug reported with atom. I've not noticed that slowness before with other IDEs (i.e. eclipse) or during compilation ... etc. After discovering/parsing is done things work as expected, but just slower (way slower), also, when writing code to a file, sometimes the intellsense takes long time to update (hot flame appears in the status bar).

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions