<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 1, 2011, at 2:34 AM, Alexander Bolodurin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I was playing with libclang-based indexing and clang_complete plugin for Vim.<br>Having found completion responsiveness a bit lacking, I decided to track down whether it's plugin's fault.<br><br>To put the indexer under stress, I've made up an artificial test with the biggest and baddest C++ headers:<br><br>---------------8<---------------<br>#include <boost/asio.hpp><br>#include <boost/regex.hpp><br>#include <boost/thread.hpp><br>#include <boost/spirit.hpp><br>#include <boost/signals2.hpp><br>boost::<br>---------------8<---------------<br><br>...and the following minimal test program using Python bindings:<br><br>---------------8<---------------<br>from clang import cindex<br><br>def clock(f):<br> import time<br> def wrapf(*args,**kw):<br> start = time.time()<br> f(*args,**kw)<br> end = time.time()<br> print f.func_name, end - start<br> return wrapf<br><br>fname='...path to file...'<br>idx=cindex.Index.create()<br><br>@clock<br>def parse():<br> global tu<br> opts = ['-I/opt/local/include'] # MacPorts Boost path<br> tu=idx.parse(fname,opts)<br><br>@clock<br>def complete():<br> c = tu.codeComplete(fname,6,8)<br><br>parse()<br>for i in range(4):<br> complete()<br>---------------8<---------------<br><br>This is the timing I get on a Macbook Pro:<br><br>parse 3.96061992645<br>complete 3.31106615067<br>complete 3.17438578606<br>complete 3.37997102737<br>complete 3.16793084145<br><br>Each one individually isn't *too* bad, taking under 1s, though still not too responsive, with exception of signals2.hpp taking over 1.5s and, and less exotic thread.hpp taking about 1.2s.<br><br>So, the questions:<br><br>Am I misusing the library? Should I try passing some additional flags or anything else? </div></blockquote><div><br></div><div>You want to use the "default editing options" when parsing the translation unit</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; ">clang_defaultEditingTranslationUnitOptions()</span></div><div><br></div>and then reparse at least once. That will enable the various code-completion optimizations that should bring this time down significantly.</div><div><br><blockquote type="cite"><div>Or it's just the way it is? What puzzles me is that completion takes time comparable to parsing. </div></blockquote><div><br></div><div>That's because it *is* parsing :)</div><br><blockquote type="cite"><div>I take it headers have to be re-parsed in case the order of inclusion changes, as it may potentially change header contents, but 3s still seems a bit excessive.<br></div></blockquote></div><br><div>Given the volume of code you're parsing, I wouldn't call 3s excessive. On my system, GCC takes 2.7s, Clang normally takes 2.3s, and Clang when parsing for code completion takes 1.6s (it takes some shortcuts).</div><div><br></div><div>If you then turn on the optimizations I mentioned above, it goes down to 0.4s. Of course, it could always be better.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>