Improve response time of Q# standard library tests in VS code

[vadym-kl]

Describe the enhancement request

After opening tests for Q# standard library it takes around 18-20 seconds before one can go to symbol list defined in the file.
Standard library test project has 3073 lines of Q# code in 34 files.
Once Q# language server has processed the files, errors start to show up in many files, however the project builds successfully.
It looks like the definitions from the referenced standard library projects are not picked up by the language server.

To Reproduce

git clone https://github.com/microsoft/QuantumLibraries.git
cd .\QuantumLibraries\Standard\tests\
dotnet build 
code .

Expected behavior

No errors show up for projects that build successfully.
It probably should take less than 18 seconds to load project with 34 files and 3073 lines.
It would be nice if the performance was comparable to other Microsoft products like TypeScript and C#, C++ compilers.
Ideally, it would be faster because syntax and type system of Q# are simpler.

System information

• OS: Windows
• .NET Core Version: 3.1.201
• Build is run on a dedicated SSD Samsung SSD 960 EVO 500 GB, separate from the SSD on which Windows is installed
• CPU: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz set to full performance
• 32 GB RAM

Additional context

Measuring number of lines excluding blank lines and comments

To count the number of lines we used cloc with the following language definition file:

Q#
    filter rm_comments_in_strings " // 
    filter call_regexp_common C++
    3rd_gen_scale 1.36
    extension qs
    end_of_line_continuation \\$

cloc can be installed on windows with choco install cloc.

See video showing the issue.
Notice that VS code does not take full advantage of available memory and processor.

[bettinaheim]

Regarding "once Q# language server has processed the files, errors start to show up in many files, however the project builds successfully.": The content on disk is what is considered the "source of truth" for references as far as the language server is concerned (what is shown in the editor is the source of truth for source code files). If packages have not yet been downloaded, or a referenced project is not yet built, then the corresponding things will be underlined until that is done (similar to the behavior when e.g. using an F# project from C#).

[vadym-kl]

I do observe the errors when I open project after it has been built in VS Code.
I forgot dotnet build in the steps to reproduce the issue.

[bettinaheim]

@vadym-kl To clarify: did you build the test project or the standard libraries? The video unfortunately doesn't show. You should indeed not get underlining if the project has been built before (and the underlining doesn't go away until you build it).
As a side note: regarding being faster than C#, that indeed won't be possible because we in fact need to do a design time build of all C# projects in your workspace folder in order to accurately build the information you want. We can consider mitigation strategies like caching the state of your workspace folder on disk, but ultimately, if that information is outdated it will need to be rebuilt. The required time for this is also pretty independent of project size.