CPP parser responds in couple seconds for helper tool or for simple commenting line. For example applying comment:for one line in file (~30kb) from: - my project takes about 3 seconds - kdevelop takes about 4 seconds Similar time I get for helper tool. I need to wait couple seconds! This is not much comfortable behavior comparing to my hardware (check end this report). In my opinion this is serious regression comparing to kdevelop-4.7.x, where application responds in less than 1 second. I tested kdevelp-4.7.3 on Mageia 5 distribution where all are working on Sandy Bridge i5-2410M Reproducible: Always Steps to Reproduce: 1. Open project kdevelop 2. Wait till kdevduchain cache finishes its building 3. Open file following file: kdevelop-git/src/kdevelop/projectmanagers/cmake/cmakemanager.cpp 4. Jump to line: 193 In my version of kdevelop source this points to inside of loop for function: CMakeManager::targets(). Please check below all function: QList<KDevelop::ProjectTargetItem*> CMakeManager::targets() const { QList<KDevelop::ProjectTargetItem*> ret; foreach(IProject* p, m_projects.keys()) { ret+=p->projectItem()->targetList(); } return ret; } I comment line starting with: "ret+=" Actual Results: need to wait at least 3 seconds for applying comment (changing color this line) Expected Results: applying comment (changing color this line) should take less than 1 seconds (at least on processor compared to i5 Sandy Bridge / Ivy Bridge). My hardware is following: SkyLake i7-6700 + SSD m4 Crucial 128GB. I observe the same behavior (the need of waiting couple seconds on respond) on Sandy Bridge i5-2410M + HDD. My settings for "Background parser" are following: - checked: "Enabled Background Parser" - Delay: 500ms - Maximum Number of threads My settings for "Clang Language Support" are following: all checked, so: - Add macros to code-completion - Enable Look-ahead code-completion - Forward declare assistant I tested on version (day of build: 2016/10/17): kdevplatform-git-debug-5.0.2.r13464 kdevelop-git-debug-5.0.2.r23476 Running environment: Plasma 5.8.1, Qt-5.7.0, KF-5.27, kernel 4.7.6-1-ARCH x86_64 Distribution Antergos (up-to-date).
The problem is that while the background parser is running for kdev-clang, generating completion items is very slow ... so we explicitly added a longer delay for some edits, such that the update doesn't overlap with the user requesting completion. I see your point though, and I'm still not sure what to do about it.
i have seen this issue as well.. my perspective on this is that maybe the background parser doesnt need to run as often? some things i change i would much prefer to have the quick completion over parsing. maybe a hotkey to manually call background parser for the current file and an option somewhere to reparse the whole project?
@Ian Haber I think parser working in background is required to properly update the "Problems". I mean update on a regular basis. I wonder why parser running for kdev-clang is such slow, even on strong hardware?
i think the parser is required to update the problems maybe, but it shouldnt have to reparse the whole file just to get the completion for foo->bar(). if i'm adding to the file in such a way that should just do completion but shouldnt affect the rest of the file... it should just give me completion without reparsing.
That's exactly the point, by delaying the parser a bit longer we get less cases where completion has to wait for it. The background parser needs to run automatically after every change, that is not debatable. We cannot even update highlighting properly without doing that.
Parser must be run automatically after every change. This is obvious. So I repeat the question: "Why the parser running for kdev-clang is such slow, even on strong hardware?" @Sven. You said: "we explicitly added a longer delay for some edit". Is this delay hard coded? Is this delay can't depend on power of processor? Is not possible to create bigger cache and hold it in memory? I think IDE is not the application running couple times a day.
Most of the delay you see is a delay, not the parser being slow. The point is that, right now, as soon as the parser starts you need to wait for it to finish before you can generate a completion list. Thus the delay, and thus changing the delay based on processor speed doesn't help -- it's meant to match your typing speed, not the processor. The parser is slow because parsing C++ correctly is complicated. This issue has nothing to do with the size of whatever cache you're thinking about.
is the delay a set time or does it stop delaying as soon as the parser is done?
Sorry I'm not sure I got you fully :/. Parser is not slow, only delay(s) make it works slow :/. I understand that parser has to finish its work before I can generate completion list or helper content. So how to decrease this delay? I observe similar delays on i5 Sandy Bridge and i7 SkyLake (~3 sec.) and for sure there is big difference in power between both CPUs, so why this delay is so similar? I don't understand why processor speed can't help here. So what will help? I don't type super fast. Sometimes faster, sometimes slower. Function completer is due to helps me in completing code. Waiting on parser till it finish its work discourages of using completing or helper tool :-/. For me parser is slow, because simple commenting makes I have to wait couple seconds. Looking at I my example, what parser has to make analysis? This is couple lines of function and loop with one line body :/. I'm not aware how this parser works, but this is very uncomfortable during work on code :-(. > The parser is slow because parsing C++ correctly is complicated. Parser in KDevelop 4.7.x works much faster. For me it looks like some issue related with clang. I suppose that in previous KDevelop parser didn't base on clang. I don't know maybe its parsing wan't enough correctly :/. Some times ago Milian made some optimizations in parser. I was hope that parser thanks that will speed up, but this didn't happen :(.
When you change the code, a background process is started with a certain delay, which updates the code model (highlighting, ...). _While_ this process is running, the clang-based cpp support cannot generate completion lists, it has to wait. Before it is started and after it is finished all is fine. This is an unfortunate limitation of libclang, the old kdevelop cpp parser didn't have that. Thus, we added this "long" delay as a workaround, and thus it doesn't help to scale this delay with CPU speed either. I know this is unfortunate, but I'm not capable of improving the situation in clang/libclang, and I don't have the time to work into that either. Maybe Milian has an idea.
i just set the background parser delay to a much longer time, so that i can basically modify as much as a want and then stop typing after saving for reparse. it still seems to be slower on offering completion than v4. it still seems to wait about a half second before offering completion even when the parser isnt going to run for another 3 seconds.
@Sven. Thanks for clear explanation. I hope Milian will find some solution on this annoying issue :/. @Ian. I set it on 4500 ms, but it doesn't help. Still after comment one line I have to wait couple seconds.
Yes, setting the delay to a longer value doesn't update the highlighting faster -- on the contrary, it delays it even more ;) We should probably remove the user-defined delay altogether. I don't see what it's good for.
the user defined delay works really well for my use case :). i fixed my problems altogether by just turning that timer up. i can now type whatever i want and get autocomplete on it before the reparse. This has sped up my workflow considerably (back to 4.7 speeds). Still having issues with templated qt classes though (BUG 371217)
I think most of this bug should be fixed in 5.1.80+, at least when editing cpp files.
Perhaps it would help to have a small indicator about the parser state, so one knows whether the parser is still preparing stuff, so one has to sigh and wait :), or if things should work (tm) and might be broken for other reasons. Given there is a technical reason for the delay and that it affects user experience, IMHO it makes sense to also expose the parser state to the user, so they have a better understanding of the tool and know what to expect.