kdev-clang

Milian Wolff mail at milianw.de
Wed Jan 28 15:48:36 GMT 2015


On Wednesday 28 January 2015 14:31:45 René J.V. Bertin wrote:
> On Wednesday January 28 2015 12:25:11 Milian Wolff wrote:
> > That's missing llvm-config as far as I can see. Do you even have a
> > libclang.so that provides the Clang C API? What about the headers - are
> > they available?
> Yes, llvm-config is missing, as I said :)
> 
> Not being sure what you need, how about a more or less complete listing of
> the Developer directory inside the Xcode bundle (i.e. excluding platform
> SDKs): https://paste.kde.org/pwa2qlzdy If you can give me a few headerfile
> names, I can do a more specific search.

It's missing the important CXString.h and Index.h headers. See e.g.:

$ ls /usr/include/clang-c
BuildSystem.h  CXCompilationDatabase.h  CXErrorCode.h  CXString.h  
Documentation.h  Index.h  module.modulemap  Platform.h

<snip>

> > I wouldn't waste time on using it. You are beating a dead horse here.
> 
>                                              ^ remove 1 letter and you'll
> have my full attention ;)
> 
> I was never planning on using it if it's that outdated. Just on figuring out
> how to get it to build against Apple's toolchain, which would be a good
> thing to have for the current version too. IMHO.

True.

> > that regard. Pure indexing of a project is, in my tests, considerably
> > faster now that we are smarter at handling headers and translation units.
> > Whats still a bit slow is code completion, but mostly because we didn't
> > spent a good amount of time investigating the performance there yet.
> 
> Is there any reason to think that those observations also (or don't) hold
> for low-end hardware? Just asking so I know if it's worth the hassle
> building the component on that same slow hardware (which could of course
> use any possible kind of performance gain).

Even if it's a single-core machine, then it should be in the same ballpark:

oldcpp:
 Performance counter stats for 'duchainify -t 1 .':

      14188.898252      task-clock (msec)         #    0.964 CPUs utilized          
             4,433      context-switches          #    0.312 K/sec                  
               156      cpu-migrations            #    0.011 K/sec                  
            37,567      page-faults               #    0.003 M/sec                  
    39,777,712,153      cycles                    #    2.803 GHz                     
[49.80%]   
    34,877,083,049      instructions              #    0.88  insns per cycle         
[74.85%]
     6,674,027,980      branches                  #  470.370 M/sec                   
[75.11%]
       116,696,017      branch-misses             #    1.75% of all branches         
[75.13%]

      14.711430398 seconds time elapsed

kdev-clang:
 Performance counter stats for 'duchainify -t 1 .':

      14039.806922      task-clock (msec)         #    0.972 CPUs utilized          
             4,497      context-switches          #    0.320 K/sec                  
               198      cpu-migrations            #    0.014 K/sec                  
            37,640      page-faults               #    0.003 M/sec                  
    39,264,884,279      cycles                    #    2.797 GHz                     
[50.02%]
    34,266,616,611      instructions              #    0.87  insns per cycle         
[75.19%]
     6,575,382,344      branches                  #  468.339 M/sec                   
[74.84%]
       116,173,419      branch-misses             #    1.77% of all branches         
[75.18%]

      14.444488657 seconds time elapsed

So not really worth updating if you expect it to magically become faster.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de



More information about the KDevelop mailing list