<div dir="ltr"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hi Dean,</span><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Thank you very much for the suggestion!<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Having an index which can be searched and compacted at the same time would</span><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255);float:none;display:inline"><span> </span>undoubtedly</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>be amazing.</span><span> </span>We would certainly consider it and think about how this could fit into the design.</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Right now, however, I think we should focus on immutable index model. The most building blocks (searching/query routine) are unlikely to change in the future, so we would like to start with these. The plan is to implement an immutable index and rebuild it once in a while and to get an idea of whether it is a performance bottleneck or not. Once everything is in place and we could get an idea of what parts of interaction with symbol index cause performance overhead, we can start optimizing and changing these parts.</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">As Eric and Marc-Andre mentioned before, we are looking into efficient index building, too, and I think both problems are connected and I think we should investigate possible solutions.</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Kind regards,</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Kirill Bobyrev</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 17, 2018 at 6:19 AM Dean Michael Berris <<a href="mailto:dean.berris@gmail.com">dean.berris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kirill,<br>
<br>
Thanks for posting this!<br>
<br>
I wondered while reading the proposal whether you've considered the<br>
model used by Bigtable [0] where you can have "compactions" or<br>
re-indexing in an incremental manner. You can then do the trigraph<br>
indexing be done quickly, and maintain different versions of the<br>
trigraph indexes that can be concurrently searched while compactions<br>
are happening in the background as new changes are committed through<br>
the LSP API. This will always be a trade-off, but merging the trigraph<br>
indices can happen independently without resorting to mutating the<br>
actual index.<br>
<br>
Cheers<br>
<br>
[0] <a href="https://ai.google/research/pubs/pub27898" rel="noreferrer" target="_blank">https://ai.google/research/pubs/pub27898</a><br>
On Mon, Jul 16, 2018 at 8:04 PM Kirill Bobyrev via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Dear LLVM Community,<br>
><br>
> over the past few weeks, we (Google C++ Language Tools Team) have been working on the efficient symbol index proposal for Clangd. The goal is to improve overall Clangd performance by reducing the latency of different kinds of symbol search queries, such as the ones used for code completion. The plan is to follow the proposed design and replace existing implementation by the end of September.<br>
><br>
> We are happy to get feedback and comments on the proposal: suggestions are welcome!<br>
><br>
> The link to design document: <a href="https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit?usp=sharing</a><br>
><br>
> Kind regards,<br>
> Kirill Bobyrev<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
-- <br>
Dean<br>
</blockquote></div>