KDevelop 5 too slow?

[René J.V. Bertin]

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().

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?

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.

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 ...

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...

> 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!

R
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KDev-ClangDUchain-TimeProf1.png
Type: image/png
Size: 213938 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20170504/f604cb44/attachment.png>