KDevelop 5 too slow?
mail at svenbrauch.de
Wed May 3 21:28:41 BST 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the KDevelop