KDevelop 5 too slow?
René J.V. Bertin
rjvbertin at gmail.com
Wed May 3 08:36:38 BST 2017
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.
The OP mentions slowness in auto-complete. For me that means the culprit almost has to be the unknown declaration fixer. I had the same issue, also in very simple Qt projects (on Mac it's even worse) and traced it to that part of the code. And it seems logical in hindsight: auto-completion is applied to incomplete patterns and 99% of the time those are unknown declarations. The OP has an SSD though, which should make a considerable difference unless he also has (part of) his headerfiles on a networked volume.
FWIW, the best way to measure times here with as little influence from the unknown declaration fixer is probably to select an erroneous variable or function name, wait until that fixer has done its thing, and then use paste (Ctrl-V) to correct the pattern.
I also notice that the OP uses clang-4.0 . I wasn't even aware it was finally released, it wouldn't be a pre-release version built with assertions, would it? In my experience with earlier versions there is a very significant performance penalty to that. And maybe that version has continued the trend of being slower than its predecessor (or uses more memory when used the way KDevelop does)?
More information about the KDevelop