[cfe-dev] Adding indexing support to Clangd

Marc-André Laperle via cfe-dev cfe-dev at lists.llvm.org
Mon May 22 21:02:38 PDT 2017


Those are good points. I think we'll have to see how fast the indexing without caching and then go from there. I think the precompiled preamble sounds useful at least for opened editors for quick parsing as there can be many reparsings of the same file without anything changes in the inclusions (while typing, etc). I think reusing the information from the previous version is a good compromise but we also have to make sure building the index for the first time is not too long or at least make sure that there is sufficient functionality available for users to start working and communicate that some functionality is not available.


Cheers,

Marc-André

________________________________
From: Ilya Biryukov <ibiryukov at google.com>
Sent: Friday, May 19, 2017 8:27:48 AM
To: Marc-André Laperle
Cc: Doug Schaefer; via cfe-dev; zaks.anna at gmail.com; Zoltan Porkoláb; Marton Csordas
Subject: Re: [cfe-dev] Adding indexing support to Clangd

Hi everyone,

The problem with PCHs(either chained or not) is that they only work for the source file,
i.e. you can only use it when you start the new file from scratch, right? For header caching we
really want to reuse whatever information we have cached even if it's included in a different
context(i.e. the order of includes is different in the other translation unit), which is not possible with PCHs.

My point is that it's not at all straightforward how(or if?) the PCHs can improve performance of processing
the same header twice.

And as long as building an index is as fast as a recompile and we can reuse information from the previous
version(slightly outdated) the index while the new version is building, we can probably get a good enough
UX without any compromises on correctness(and introducing additional complexity, since I don't think there's
a way to do header caching without significant changes to clang itself).

CLion indeed has a custom parser and serialization format, it's not clang-based.


On Thu, May 18, 2017 at 10:33 PM, Marc-André Laperle via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

Yeah, it sounds like a good approach to tackle header caching a bit later. "Precompiled preamble" looks promising so we can keep this in mind as we go.


Cheers,

Marc-André

________________________________
From: Doug Schaefer <dschaefer at blackberry.com<mailto:dschaefer at blackberry.com>>
Sent: Thursday, May 18, 2017 10:44:18 AM
To: Marc-André Laperle; via cfe-dev
Cc: zeratul976 at hotmail.com<mailto:zeratul976 at hotmail.com>; zaks.anna at gmail.com<mailto:zaks.anna at gmail.com>; Dániel Krupp; Zoltan Porkoláb; Marton Csordas
Subject: Re: Adding indexing support to Clangd

On 2017-05-17, 6:38 PM, "Marc-André Laperle"
<marc-andre.laperle at ericsson.com<mailto:marc-andre.laperle at ericsson.com>> wrote:
>  - For header caching, I wonder if it is possible to reuse the
>precompiled header support in Clang. There would be some logic that would
>decide whether or not a precompiled header could be used depending on the
>preprocessing context (same macro definitions, etc).

I¹m not certain header cacheing is needed right away. We did it in the CDT
because our parsers were fairly slow and indexing a project took a very
long time. I have hope that clang would be faster. At the very least, you
would want cacheing to be optional so you need to be able to work without
it. But make sure you have the architecture to graft it in later.

In CDT we cheated a lot to gain performance and the cost of accuracy. The
results are still very good so its an interesting balancing act.

Doug Schaefer
Eclipse CDT Project Lead


_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




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


More information about the cfe-dev mailing list