[cfe-dev] Clang indexing library performance

Alexander Bolodurin alexander.bolodurin at gmail.com
Sat Oct 1 02:34:54 PDT 2011

I was playing with libclang-based indexing and clang_complete plugin for Vim.
Having found completion responsiveness a bit lacking, I decided to track down whether it's plugin's fault.

To put the indexer under stress, I've made up an artificial test with the biggest and baddest C++ headers:

#include <boost/asio.hpp>
#include <boost/regex.hpp>
#include <boost/thread.hpp>
#include <boost/spirit.hpp>
#include <boost/signals2.hpp>

...and the following minimal test program using Python bindings:

from clang import cindex

def clock(f):
    import time
    def wrapf(*args,**kw):
        start = time.time()
        end = time.time()
        print f.func_name, end - start
    return wrapf

fname='...path to file...'

def parse():
    global tu
    opts = ['-I/opt/local/include'] # MacPorts Boost path

def complete():
    c = tu.codeComplete(fname,6,8)

for i in range(4):

This is the timing I get on a Macbook Pro:

parse 3.96061992645
complete 3.31106615067
complete 3.17438578606
complete 3.37997102737
complete 3.16793084145

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.

So, the questions:

Am I misusing the library? Should I try passing some additional flags or anything else? Or it's just the way it is? What puzzles me is that completion takes time comparable to parsing. 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.

I'd appreciate any clues.

More information about the cfe-dev mailing list