Intellisense server (Indexing files) is too slow on Linux

[aabuelenin]

OS: RHEL 7.3
VSCode version: 1.21.1
C/C++ extension version: 0.16 insiders

Hello, I've the same version of vscode and cpptools ext installed on windows. If I open the same folder on windows, it takes the indexer just a few seconds to finish working (the hot flame and the database icons disappear) and intellisense/go to definition ... etc are working fine.

On Linux it takes way longer for the indexer service to finish processing, during that time when I hover over the symbols most of them will show the correct declaration (in the tooltip) but if I try to navigate to definition or declaration, sometimes I get this error 'no definition found for ...'.

The indexer seems to start everytime I restart vscode and it keeps working for at least 10 minutes.

Why the indexer is taking that long on Linux but not on Windows? Is max_user_watches has something to do with that? it's currently set to 8194.

[sean-mcmanus]

Hover over the database icon in the bottom right to see how many files are being processed and the speed of the processing. When you restart VS Code after the database is built, there should be no parsing operations being reported with the database icon tooltip (it should just be discovering files). You may need to change your browse.path (using at the end to avoid recursion). Make sure limitSymbolsToIncludedHeaders is true as well.

[aabuelenin]

@sean-mcmanus when I hover over the icon the number of files being discovered grows slowly till it reaches a number greater than 300k files. The workspace I'm using vscode with contains a huge number of files, eventually, the DB and hot flame icons disappear but it takes time.

LimitSymbolsToIncludedHeaders is set to true.

Sorry, I've not got how I can prevent recursion.

I don't have sudo access on the machine and couldn't try increasing the limit of file_watchers, could this improve the performance? I feel it's irrelevant but need your opinion.

[sean-mcmanus]

You should probably remove the ${workspaceRoot} or ${workspaceFolder} from your browse.path and instead just add the specific folders you want to have symbols parsed, and using something like ${workspacFolder}/* will only parse the root and not subdirectories.

I don't think the file_watcher limit is related or will improve performance (I hit the file watcher limit on my machine when I have multiple VS Code instances open with big folders).

[aabuelenin]

Thanks @sean-mcmanus, I tried that but it didn't solve the problem, the only thing that makes the indexer fast is removing from the browse path a folder that contain 160K+ code files, that folder isn't part of the workspace, but a few thousands of these code files are referenced by the workspace.

I don't have a problem if I've to leave vscode running over-night to index all files, but it just takes too long to warmup everytime it's restarted.

Do you think vscode intellisense can work with that number of code files?

[sean-mcmanus]

Can you remove the path with 160k files and only use the most important sub-paths? LimitSymbolsToIncludedHeaders will prevent the 160k files from being parsed, but we still need to scan the files to see if they exist so we can parse them later when a source file #includes such a file. There are things we could do speed up scanning or to skip it, but that would bypass our code that cleans up our database when files no longer exist on disk.

One related issue is #1481 .

[aabuelenin]

Thanks, as a workaround I create symbolic links for the required files only, the startup time dropped to around 1 minute instead of 15 (time starting from when the DB icon appears till it disappears). That's a great improvement but I still feel there's something wrong, running vscode on windows with almost identical configuration can load in less than a couple of seconds.

I tried uninstalling all the extensions including cpptools, then installed just cpptools and still got the same result.

My config on Linux is:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"/usr/include",
"/usr/local/include",
"${workspaceRoot}/../include",
"${workspaceRoot}/dir1/include",
"${workspaceRoot}/dir2/include",
"${workspaceRoot}/dir3/src/c++",
"${workspaceRoot}/dir4/include",
"${workspaceRoot}/dir5",
"${workspaceRoot}/dir6/src",
"${workspaceRoot}/dir7/src",
"${workspaceRoot}/dir4/sub1/sub2/sub3/sub4/include"
],
"defines": [],
"intelliSenseMode": "clang-x64",
"browse": {
"path": [
"/usr/include/",
"/usr/local/include/",
"${workspaceRoot}/../include",
"${workspaceRoot}/dir1",
"${workspaceRoot}/dir2",
"${workspaceRoot}/dir3/src/c++",
"${workspaceRoot}/dir5",
"${workspaceRoot}/dir6/src",
"${workspaceRoot}/dir7/src",
"${workspaceRoot}/dir4"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
},
"cStandard": "c11",
"cppStandard": "c++11",
"compilerPath": ""
}
],
"version": 3
}

What I can do to troubleshoot this issue?

[sean-mcmanus]

So you're seeing slowness on just Linux and not windows for the same workspace? Usually, that indicates a difference in the system libraries. You can increase the logging level to something like "6" to see more details of the processing, but be sure to get rid of that afterwards or it'll slow stuff down.

Just a warning, if the compilerPath is blank, we'll use the "guessed" one, which you can see via opening a new folder and doing an Edit Configuration. We want to fix this via updating the compilerPath to the guessed one.

[aabuelenin]

Yes, it's pretty fast on windows. Thanks for advice, will give that a try. btw, I'm connecting to vscode on linux over x11, I don't think that can cause a slowness.

[aabuelenin]

The default intellisense engine is crashing, I removed the browse path info and fored using the default engine, now it's crashing continuously, the log panel is showing errors similar to:
Failed to read response from server: 18
Failed to send request to server: 3
IntelliSense engine is not responding. Using the Tag Parser instead.

The stacktrace for the intellisense server:
#0 0x00000000006c5a03 in scan_expr_full ()
#1 0x00000000006cc463 in scan_void_expression ()
#2 0x00000000008203ec in expression_statement ()
#3 0x000000000081e92e in statement ()
#4 0x000000000081a511 in compound_statement_full ()
#5 0x000000000072b611 in scan_function_body ()
#6 0x000000000072d524 in function_definition ()
#7 0x000000000068ff02 in scan_nonmember_declaration ()
#8 0x00000000006945c2 in namespace_declaration ()
#9 0x000000000068d564 in scan_nonmember_declaration ()
#10 0x00000000006945c2 in namespace_declaration ()
#11 0x000000000068d564 in scan_nonmember_declaration ()
#12 0x00000000006945c2 in namespace_declaration ()
#13 0x000000000068d564 in scan_nonmember_declaration ()
#14 0x0000000000692688 in declaration ()
#15 0x0000000000584769 in end_of_parse_notification ()
#16 0x0000000000876e29 in process_translation_unit ()
#17 0x000000000060d2a7 in edg_main ()
#18 0x000000000088ec1c in edge_compiler_main(int, char const**) ()
#19 0x0000000000585517 in pre_parse(int, char const**, a_scout_parser_interface&, edge::translation_unit*) ()
#20 0x000000000054f7c1 in a_compiler_thread::compiler_thread_routine(a_compiler_thread*) ()
#21 0x000000000057c9be in void* std::__1::__thread_proxy<std::__1::tuple<void ()(a_compiler_thread), a_compiler_thread*> >(void*) ()
#22 0x00007fa622ef5dc5 in start_thread () from /lib64/libpthread.so.0
#23 0x00007fa622c2473d in clone () from /lib64/libc.so.6

Found that a specific directory causes the crash when added to the includePath (it's the most important directory for me), but removing it causes this error
Quick info operation failed: FE: 'Compiler exited with error - No IL available'

the directory in question contains 300 files, so I'm not able to isolate the issue and find which expression/file is causing the crash.

[aabuelenin]

Modifying the compiler path and adding some missing includes solved the crashing, but I wish if the intellisense server showed more info instead of just crashing.

Does the intellisense engine provides any logs? The code for the engine isn't open source, am I correct?

[sean-mcmanus]

scan_expr_full is a known issue causing about 30% of our crashes (our highest hitter). VS 2017 had the bug, but we believed it had been fixed with the changes we pulled in for 0.16.0-insiders, but if it's not fixed, then it'll be at the top of the list to fix for next time.

Our engine and parser code is not open sourced...and the parser doesn't have much logging enabled in the release build.

[aabuelenin]

Thanks for your help, I generated compile_commands.json file and started using it, that solved the crashing issues.

[s-martin]

@sean-mcmanus
Thanks for the hint to remove ${workspaceRoot} from browse.path to increase performance.

It would probably help other users to add this hint to the c_cpp_properties.json documentation!