KDevelop 5 too slow?

[Milian Wolff]

On Wednesday, May 3, 2017 10:28:41 PM CEST Sven Brauch wrote:
> On 03/05/17 09:36, René J.V. Bertin wrote:
> > On Wednesday May 03 2017 00:38:10 Sven Brauch wrote:
> >> On 03/05/17 00:19, René J. V. Bertin wrote:
> >>> Isn't that because of the unknown declaration fixer thingy which
> >>> has a knack of scanning and rescanning a potentially huge number
> >>> of include files, on the main/gui thread?
> >> 
> >> No, different issue, this one is in the parse jobs.
> > 
> > I presume that the parser also scans through headerfiles so the
> > underlying reason could well be the same.
> 
> I don't think so. Kevin and me investigated this problem a bit at the
> last sprint. The general issue is roughly, while the parser is running,
> no new completion items can be generated; this is why we introduced the
> long delay when typing on a single line intentionally (it shouldn't
> start running the background parser while you're still typing in a
> single line and need completion).
> 
> 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
> sometimes very slow and nobody could figure out why yet. I feel like
> some code cache (precompiled header cache?) is dropped under some
> circumstances which happen on some projects erraneously, but not on
> others. Maybe strange paths (non-normalized, ...) have something to do
> with it, but that's just guesswork now.
> 
> 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.

I just profiled a simple file in VTune and there the delay of 3s is really 
killing the perceived performance. Simply returning DefaultDelay from 
ClangSupport::suggestedReparseDelayForChange speeds things up dramatically.

I actually think that always waiting for 3s is too long. We need to find a 
different behavior for this, which may need more changes elsewhere. Here are 
some comments on how it should work from my POV:

- user is typing and the default delay (500ms) catches fast typing and only 
once the user has finished typing will we wait 500ms until we kick of the 
parse job

- user is typing, waits too long, and we kick of a parse job, the user 
continues to type -> this case is, afaik, currently unhandled. we should abort 
the parse job in such cases, if at all possible. But looking at clang's 
Index.h, this doesn't seem to be possible, which is very unfortunate :( At 
least not with the current API we are using. I wonder if we may need to use 
clang_indexSourceFile instead...

- until the above is fixed, we'll have to reduce the 3s delay based on some 
heuristics. i.e. we should probably return the default delay when

-- the file is $small (whatever that means)
-- the file is a .cpp file and we have parsed it before (reparsing is usually 
quite fast in my experience)
-- the user entered a string after which he expects code completion to work, 
like any of the following operators (and probably more): (,:<>.

Sven, Kevin - what did you use for benchmarking back then? I.e. is there a 
reproducible test case that we can use to find a good value for the delay 
here? 3s clearly isn't a good value.

Thanks

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