slow code completion when #include <boost/algorithm/string.hpp>

[ahmednofal]

Hello, thank you for ur amazing work.

I wanted to ask you if it is something related to clang_complete or is it my libclang version

I am using this option in my .vimrc:

let g:clang_library_path='/usr/lib/llvm-3.8/lib/libclang.so.1'
let g:clang_use_library = 1
let g:clang_complete_auto = 0

Whenever I hit it jumps through the entirety of boost libraries trying to complete. I am guessing because it is jumping through all of the includes in the string.hpp file in boost library.

Also this happens everytime, so it is also not caching the results although I tried

let g:clang_library_path='/usr/lib/llvm-3.8/lib/'

with same results. I have went through some of the pre-open issues and found some of them suggesting that the cached results are not there because the rest of libclang so files are not in same directory as libclang.so.1

but stil pointing to the directory and not the file itself does not work and blurts out an error that it can not find the clang library file.

I think just forcing clang_complete through .clang_complete to certain directories might be best.

Is it possible to force clang_complete not to go through the #includes ?

I used this https://stackoverflow.com/questions/10541411/how-to-reduce-the-time-of-clang-complete-search-through-boost

but this hardly is a fix. hoping someone can jump in. "

Thanks.

[xaizek]

Hi,

I don't think it's possible. At least I don't remember any way of skipping includes, but it was awhile.

It also doesn't make much sense because libclang needs to go through includes in order to parse your code. Otherwise it might produce garbage instead of results (like all globals that it found, which is a weird behaviour).

You might want to consider out-of-process indexing completion engines via something like vim-lsp. Lags might be less noticeable there because it will happen in background. Haven't tried them myself, but it could be an improvement.