KDevelop 5 too slow?
René J.V. Bertin
rjvbertin at gmail.com
Thu May 4 17:26:46 BST 2017
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213938 bytes
Desc: not available
More information about the KDevelop