KDevelop 5 too slow?

[Milian Wolff]

On Tuesday, May 30, 2017 4:23:55 PM CEST René J.V. Bertin wrote:
> On Tuesday May 30 2017 15:18:51 Milian Wolff wrote:
> >- 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
>
> Yes. I've tried to implement the simplest possible approach to achieve this
> for unknown declaration problems (got downvoted because it uses a nested
> event loop but it does make things bearable for me).

Again, this has nothing to do with the unknown declaration problems. And your 
patch was simply of unacceptable quality.

> Even if you can't
> abort the parse job (properly short of killing the thread?), can't you
> simply stop waiting for it to complete and ignore the results whenever they
> become available?

No, because clang internally keeps track of the parse job, see Sven's mail on 
that matter. We will probably need to extend the clang API to get a way to 
abort a parse job properly.

> >- 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
> 
> I have already found myself bumping those 500ms value significantly (to
> 2000). Maybe this is completely beside the point, but couldn't it be useful
> to make the timeout (the default 500ms value) adaptive (optionally or
> always) within a reasonable range of values? That is, increase the
> threshold if the timeout is triggered inappropriately too often, decrease
> again when waits become unnecessarily long. There are adaptive staircase
> methods (e.g. QUEST) from psycho-physics research that could probably be
> ... adapted to serve here if similar algorithms don't already exist in GUI 
> context. A similar thing might be possible with the 3s delay

KISS say's no to this proposal.

> >-- 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)
> 
> Keep track of how long the last (full) parse took, per file, and use that
> information some way?

Not reliable, as reparsing is very different from parsing. And if any header 
inbetween was updated, we need to update everything, which again slows down 
things. So no.

> >-- the user entered a string after which he expects code completion to
> >work, like any of the following operators (and probably more): (,:<>.
> 
> Define a shortcut to trigger completion, some modifier combination with the
> Tab key by default?
>
> I probably wouldn't mind an option anyway to make completion manual because
> too often I find that it finds and selects a (or another) completion just
> when I hit the enter key (or even just after). I never really had that with
> other IDEs or completion mechanisms.

Ctrl + Space is that shortcut. It's actually a good idea to force-update the 
document in that situation.

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