<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 9, 2021 at 5:42 PM Demi Marie Obenour via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/9/21 12:09 PM, Sam McCall wrote:<br>
> On Tue, Nov 9, 2021 at 4:38 PM Demi Marie Obenour via cfe-dev <<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> <br>
>>>> * I think you are better off spending your time on optimizing the<br>
>> correct<br>
>>>> parser infrastructure.  I'm sure more can be done - particularly in<br>
>> terms<br>
>>>> of caching, persisting and resusing state (think like PCH and modules<br>
>> etc).<br>
>>>><br>
>>> We have worked on projects over several years to improve these things<br>
>> (and<br>
>>> other aspects such as error-resilience). We agree there's more that can<br>
>> be<br>
>>> done, and will continue to work on this. We don't believe this approach<br>
>>> will get anywhere near a 100x latency improvement, which is what we're<br>
>>> looking for.<br>
>><br>
>> What about pushing the state to a server?  Have a server that has the<br>
>> entire<br>
>> index, and keeps it up to date whenever a VCS commit is made to the main<br>
>> branch.<br>
> <br>
> We have this for clangd's index: <a href="https://clangd.llvm.org/guides/remote-index" rel="noreferrer" target="_blank">https://clangd.llvm.org/guides/remote-index</a><br>
> It works great (try it out with LLVM!) but needing to deploy a server means<br>
> 90% of users won't ever touch it.<br>
> <br>
> (A shared repository of serialized ASTs *is* something we're considering in<br>
> a tightly controlled corp environment but the barriers are pretty huge:<br>
> size, security and it only works if everyone uses the same precise version<br>
> of the tool. And it only makes sense at all if you're sure you can download<br>
> 300MB in less than 30 seconds!)<br>
Indeed that is not going to be useful outside of an on-premises corporate<br>
environment with extremely fast network connectivity.  And the security<br>
considerations are stringent, especially since clangd is written in C++ and<br>
I am not sure it can be trusted with untrusted input.<br>
<br>
Could an index be persisted to disk, reloaded at startup, and incrementally<br>
changed as the user edits?  That would avoid having to have a daemon<br>
constantly running.<br></blockquote><div><br></div><div>Such an indexer architecture is what most people are using for codebases less than a few million lines, which is almost all of them.  Only a handful of companies like Google, Bloomberg, etc have to deal with the scalability issues of codebases larger than that.  In those outlier settings I'd say a common practice is to break off just the million or so lines around what you're working on (ie it and its dependencies and some dependents), and just index that subpart.  There are then other centralized shared tools that regularly index the checked-in state across the entire codebase, when you need to venture outside of that subpart (eg to look up external refs).  The latter doesn't sync with your unchecked-in changes, but that is a small price to pay compared to using an inferior approximate parser that is always getting things wrong (go-to-definition/autocomplete/call-graph/etc regularly failing).</div><div><br></div></div></div>