KDevelop 5 too slow?

[Milian Wolff]

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.

I actually have seen this function pop up in KDevelop profile runs on Linux 
myself. Maybe there's a way to speed up this check via some lookup table, or 
by improving clang upstream.

> Working back up I note that clang::cxcursor::CursorVisitor::visit()
> apparently calls an (anonymous)::visitCursor() method in
> libKDevClangPrivate, and this call accounts for over 97% of the processing
> time.

Yes, see above - it does the heavy work so this is to be expected.

> The nice thing with Instruments is that you mostly don't have to do special
> profiling builds and can attach to a running application to sample just a
> specific operation. I didn't even build llvm/clang (4.0) with debug info,
> which save. The drawback is that you need a Mac ...

Perf or VTune are just as capable. Also, to make sure: Did you compile KDev* 
and everything else you are profiling in RelWithDebInfo mode? If not, then 
this profile output is completely useless.

> One thing I don't understand: I'm seeing 3 background threads that do the
> actual ClangDUChain work, while my session is configured to use only 2 . I
> guess it would help if the threads were given names...

There's N + 1. N for background parsing and one for parsing the active 
document, if needed.

> > Further investigations are very welcome, but I think one needs to sit
> > down with a debugger/profiler and a build of llvm with symbols and
> > figure out what happens. Guessing around on the mailing list won't find
> > it IMO.
> 
> Hope this helps then, and apologies for attaching an image!

Better than nothing.

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