KDevelop 5 too slow?

[Milian Wolff]

On Monday, May 29, 2017 10:52:00 AM CEST Milian Wolff wrote:
> On Thursday, May 4, 2017 6:26:46 PM CEST René J.V. Bertin wrote:
> > On Wednesday May 03 2017 22:28:41 Sven Brauch wrote:
> > > My memory tells me that we also timed what takes so long, and it's
> > > clang generating the completion items, i.e. not in our code. It's just
> > 
> > Looks like it when I attach the "Time Profiler" instrument on OS X and hit
> > "reload all" in KDevelop to force it to reparse a few source files. Most
> > of
> > the 25sec or so is spent in ClangHelpers::buildDUChain() which itself
> > spends over 93% of its time in Builder::visit() which in turn spends about
> > 85% of its time in clang_visitChildren().
> 
> No wonder, this is a pseudo-recursive function (visiting the AST tree) and
> does most of the work. Either look at a bottom-up profile, a caller/callee
> aggregation, or at least use a flamegraph visualization.
> 
> > I'm not very familiar reading this kind of call graph, but if you follow
> > the graph down clang_getFileLocation shows up which accounts for almost
> > 24% of the processing time on my system. That could correspond to disk
> > access, no?
> No, CPU profilers do not account for disk access. I'm not familiar with
> Instruments, but I'd be very surprised if they are different in that regard.
> For I/O profiling, there is usually a separate profiler configuration
> you'll have to use which traces context switches or syscalls.

One more thing: Notice how low the "Running Time" actually is in your profile. 
This may point to either I/O overhead or lock contention. Can you use a 
different instruments profiler configuration to find wait time in the code? 
That would allow us to get a more accurate image of what's going on. Also, 
make sure to profile the same thing. I.e. I suggest you clear the duchain 
cache before starting KDevelop with the profiler.

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