Definitions unknown after restart of VS Code

[dirkseidel]

After a restart of VS Code, definitions are still shown when hovering over the code with the mouse but pressing F12 results in definition now found error. Only after the plugin has finished the reparsing of the source files the functionality is available again.

We are working on a remote directory mounted via sshfs, so we have to have to close and restart VS Code every day. It is annoying to have to wait for a long time (20-30min) to be able to use the functionality again. As the source files usually have not changed since the shutdown of VS Code it should be possible to use the data from the most recent parsing. Also, it might be useful to not automatically start the parsing and give the user the possibility to start it manually.

[sean-mcmanus]

Yeah, we save the info in a database file, so ideally you shouldn't have to wait, so we should investigate why this is occurring. I've seen several seconds delay, but not 20-30 min. We do a file scan for new files, and parsing should only occur for new files. The browse.path is recursive and implicitly adds ${workspaceRoot} (unlike includePath), so that could cause duplicate scanning to occur if you're not careful (we haven't added code to exclude duplicate processing yet).

[dirkseidel]

Where exactly do I have to be careful? I just have one open folder which of course should be scanned recursively.
Is there anything I can provide to help fixing the bug?

[sean-mcmanus]

You should be careful not to add duplicate entries to the browse.path. ${workspaceRoot} is added to the browse.path internally, so it shouldn't be added again, nor any child paths of it, unless you change the addWorkspaceRootToIncludePath to false. You could help to fix the bug by providing a repro folder, such as with an open source project. Also, what OS are you on? I'm not able to repro a 20-30 min delay in peek definition working for a big project (it's more like 15 seconds).

[dirkseidel]

I have not given any additional paths to the source, so that should not be the problem. Unfortunately, we are not open source. Anything else I could do?
OS: Mac

[sean-mcmanus]

You could attach a debugger and provide a dmp or call stacks of the Microsoft.VSCode.CPP.Extension.darwin process during your repro. I wasn't suggesting you open source your project, but if you could check if the bug repros for you on some other open source project or if the issue is specific to your project, that would help.

[dirkseidel]

Since some update of the extension there is now a file c_cpp_properties.json in ${workspaceRoot}/.vscode where databaseFilename was set to "~/browse.VC.db". Unfortunately ~ could not be resolved and the database file was never written to disk. I changed ~ to the explicit path and now the file is present.
In our project it amounts to 1.6GB and it now takes roughly 10min after a restart to be able to access the definitions and another 20min till the red flame(?) icon disappears in VS Code. Is this what is expected or should the parsing be faster?

[sean-mcmanus]

That is expected, but the results should be saved to the database after reopening the workspace, so subsequent opens should be faster. You can make definitions be available earlier by putting them earlier in the browse.path.

[dirkseidel]

The initial scan (after deleting the database files) takes approx. one hour. But after that I am stuck with the 10min delay after restart before I can jump to definitions.
I then set "C_Cpp.addWorkspaceRootToIncludePath" to false and included all subdirectories from ${workspaceRoot} in c_cpp_properties.json (configurations->browse->path). Even when I put all subdirectories most relevant to me at the top of the list I am stuck with the 10min delay. The definitions seem to be available all at once only after all paths have been worked through.
Only when I only include the most relevant ones it of course gets fast, but that's not an option...

[sean-mcmanus]

Yeah, it looks like our database needs to add the file locations to memory at runtime. It's always been this way, but I haven't digged into the reason for this, so it could be a bug. The intelliSenseEngine features only need to compile the current translation unit, so it should be faster, but we haven't added go to def yet for that.

[sean-mcmanus]

I believe we have a fix for this bug. I don't think it will make it for Monday's update though. The bug we found only affected the Go To Definition code and was preventing it from working until all the files were re-scanned, which is unnecessary when the file was already previously added to the browse database.