<div dir="ltr"><div dir="ltr">On Tue, Nov 9, 2021 at 6:41 PM Demi Marie Obenour <<a href="mailto:demiobenour@gmail.com">demiobenour@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><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</blockquote><div>(Clangd does have this too, FWIW)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and incrementally changed as the user edits?</blockquote><div>User edits mean we need to parse new code.</div><div>Absent a pseudoparser, the only thing that parses code is clang.</div><div>Clang needs a full AST, so this step is slow.</div><div> </div></div></div>