[cfe-dev] Adding indexing support to Clangd

Ilya Biryukov via cfe-dev cfe-dev at lists.llvm.org
Mon May 29 01:58:49 PDT 2017


Hi Vladimir,

Thanks for sharing your experience.

We did such measurements when evaluated clang as a technology to be used in
> NetBeans C/C++, I don't remember the exact absolute numbers now, but the
> conclusion was:
>
to be on par with the existing NetBeans speed we have to use different
> caching, otherwise it was like 10 times slower.
>
It's a good reason to focus on that issue from the very start than. Would
be nice to have some exact measurements, though. (i.e. on LLVM).
Just to know how slow exactly was it.

+1. Btw, may be It is worth to set some expectations what is available
> during and after initial index phase.
> I.e. during initial phase you'd probably like to have navigation for file
> opened in editor and can work in functions bodies.
>
We definitely want diagnostics/completions for the currently open file to
be available. Good point, we definitely want to explicitly name the
available features in the docs/discussions.

As to initial indexing:
> Using PTH (not PCH) gave significant speedup.
>
Skipping bodies gave significant speedup, but you miss the references and
> later have to reindex bodies on demand.
> Using chainged PCH gave the next visible speedup.
>
Of course we had to made some hacks for PCHs to be more often "reusable"
> (comparing to strict compiler rule) and keep multiple versions. In average
> 2: one for C and one for C++ parse context.
> Also there is a difference between system headers and projects headers, so
> systems' can be cached more aggressively.
>
Is this work open-source? The interesting part is how to "reuse" the PCH
for a header that's included in a different order.
I.e. is there a way to reuse some cached information(PCH, or anything else)
for <map> and <vector> when parsing these two files:
```
// foo.cpp
#include <vector>
#include <map>
...

// bar.cpp
#include <map>
#include <vector>
....
```

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170529/b4002172/attachment.html>


More information about the cfe-dev mailing list