<div dir="ltr">What we do inĀ <a href="https://github.com/Andersbakken/rtags">https://github.com/Andersbakken/rtags</a> is to preemptively generate completion results whenever the cursor is moved (with a short delay) and then cache them for faster lookup. This seems to help a little bit at least.<div><br></div><div>Anders</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 11, 2016 at 1:41 PM, Milian Wolff via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Donnerstag, 7. Januar 2016 21:34:10 CET Maksym Taran via cfe-dev wrote:<br>
> Hello!<br>
><br>
> I'm looking into improving how an autocomplete system at Google<br>
> computes semantic<br>
> autocompletions for a given C++ file + line + column. Currently, it's<br>
> mostly just calling out to clang_codeCompleteAt<br>
</span>> <<a href="https://github.com/llvm-mirror/clang/blob/52ed5ec631b0bbf5c714baa0cd83c33eb" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/clang/blob/52ed5ec631b0bbf5c714baa0cd83c33eb</a><br>
> fe0c6aa/tools/libclang/CIndexCodeCompletion.cpp#L798>, and that's where<br>
<span class="">> we've been seeing high latency.<br>
><br>
> A particular problem we're having is that when we try to autocomplete just<br>
> within some scope (that is, just inside a function body, rather than after<br>
> a . or -> etc), calling that method returns *all* possible autocompletion<br>
> results, which includes all constants and class names defined in all the<br>
> transitively included files as far as I can tell. This is technically<br>
> correct, but in practice takes on the order of seconds to return, which is<br>
> much longer than the desired timeframe for autocompletion results.<br>
<br>
</span>How many results do you get after this delay? Using KDevelop to work on code,<br>
I've never seen such long delays just for the code completion stage. What<br>
takes a long time is the initial parse with clang_parseTranslationUnit2. I<br>
hope you guys have some sort of daemon which can keep the TU alive? Make sure<br>
you pass CXTranslationUnit_PrecompiledPreamble, but note that the current<br>
stable releases of clang won't actually save the precompiled preamble to disk<br>
until you call clang_reparseTranslationUnit at least once. It's easy to check,<br>
just look at /tmp and see whether you have preamble-*.pch files in there. Once<br>
you do all of that, you can easily get an order of magnitude increase in<br>
performance.<br>
<span class=""><br>
> So I'd<br>
> like to know if there's some way I can get a smaller set of autocompletions<br>
> more quickly, e.g. by asking clang to complete only on method names and<br>
> locals, or by giving a time limit to get results. I didn't see how I might<br>
> do that in the documentation<br>
</span>> <<a href="http://clang.llvm.org/doxygen/group__CINDEX__CODE__COMPLET.html#ga50fedfa85" rel="noreferrer" target="_blank">http://clang.llvm.org/doxygen/group__CINDEX__CODE__COMPLET.html#ga50fedfa85</a><br>
> d8d1517363952f2e10aa3bf> so<br>
<span class="">> I'm wondering if there are some other APIs I'm not seeing.<br>
<br>
</span>I haven't seen such an API either. How do you envision it? Some filter<br>
callback that one could pass to the clang_codeCompleteAt call?<br>
<br>
> I took a look at YouCompleteMe <<a href="https://github.com/Valloric/YouCompleteMe" rel="noreferrer" target="_blank">https://github.com/Valloric/YouCompleteMe</a>><br>
<span class="">> and it's using the same API<br>
</span>> <<a href="https://github.com/Valloric/ycmd/blob/master/cpp/ycm/ClangCompleter/Transla" rel="noreferrer" target="_blank">https://github.com/Valloric/ycmd/blob/master/cpp/ycm/ClangCompleter/Transla</a><br>
> tionUnit.cpp#L176>, so I suspect it might have the same problem. If there's<br>
<span class="">> no way to do something like this using the current API methods, I'd be<br>
> interested to know how possible/difficult would it be to implement<br>
> additional methods or options?<br>
<br>
</span>Adding methods isn't that hard, it just takes time (which I personally lack<br>
atm to advance my personal WIP patch). Just make sure you build an API that is<br>
future proof and stable, and don't forget your tests.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" rel="noreferrer" target="_blank">http://milianw.de</a></font></span><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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></blockquote></div><br></div>