I'm using kdevelop installed from the repo. It cannot parse cpp code at a good enough speed anymore on any of the projects anymore. Kdevelop 4 used to be really fast but auto completion is entirely useless with kdevelop 5. I need to wait more than 10 seconds to have suggestions. No project is safe from that bug, this is systematic. I'm at a point where returning to kdevelop 4 (or to the old parser) makes more sense for my projects. My settings for "Background parser" are following: - checked: "Enabled Background Parser" - Delay: 500ms - Maximum Number of threads: 4 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 have found the CPP parser to be next to useless compared to KDevelop 4. This has happened with all versions of KDevelop 5 I have tried, and always had to revert back to KDevelop 4. Latest test with KDevelop 5.1.1: - parsing is very slow (taking many seconds to locate a class variable). - Writing QT connect() lines shows no autocomplete at all. - Crashing while typing code (usually when typing a connect() line) I was really looking forward to the new clang based parser, but it appears to have only caused major problems, and continuing to stick with KDevelop 4 is only causing more issues that will never be resolved.
Have you tried 5.1.80? Code completion should be much faster there.
8 cores i7 cpu+fresh ssd. I gave all 8 cores to parser, delay 10-3000 doesn't matter. And it is soooooooo slow: 2-5 seconds at min for your classes, and around 8-10 seconds at max when you want to complete std/asio/etc. Word auto completion works well.
Do you have a perf profile to share? Or a project that replicates the behavior?
(In reply to Milian Wolff from comment #4) > Do you have a perf profile to share? Or a project that replicates the > behavior? No perf, and there is no need to have any project, just write 'std::' and wait. For the first ~10 minutes of coding with empty project it was about just waiting for completion by 5-8 seconds (average). After ~15 minutes and 3 restarts of the IDE it takes 2-3 sec. Is it normal? I don't know how work autocompletion in kdevelop, but start was a pain.
(In reply to Artur from comment #5) > (In reply to Milian Wolff from comment #4) > > Do you have a perf profile to share? Or a project that replicates the > > behavior? > > No perf, and there is no need to have any project, just write 'std::' and > wait. For the first ~10 minutes of coding with empty project it was about > just waiting for completion by 5-8 seconds (average). > After ~15 minutes and 3 restarts of the IDE it takes 2-3 sec. Is it normal? > I don't know how work autocompletion in kdevelop, but start was a pain. Nope, cold start on the same _empty_ project on the next day - 10 seconds, then 2 sec! It's a death for any coder. Just have tried QT Creator, and actually it is a really great IDE! Open any C++ code without creating a project and it will complete _any_ piece of a code in a nanosecond! There are no seconds, but picoseconds maybe. It will be the best autocomplete mechanism for KDevelop.
(In reply to Artur from comment #6) > Nope, cold start on the same _empty_ project on the next day - 10 seconds, > then 2 sec! It's a death for any coder. > Just have tried QT Creator, and actually it is a really great IDE! Open any > C++ code without creating a project and it will complete _any_ piece of a > code in a nanosecond! There are no seconds, but picoseconds maybe. It will > be the best autocomplete mechanism for KDevelop. My recent experience is the opposite. Qt Creator's completion for a medium-sized project used to be satisfactory. It still froze occasionally, but so does KDevelop's completion. There seemed to be a memory leak in Qt Creator's clangd triggered by switching back and forth between project configurations. After a recent update to Qt Creator 8, performance became so horrible that I was forced to disable clangd and use Qt Creator's deprecated internal code model fallback, which is less accurate but much faster and memory-efficient. Lately I rarely experience completion slowness in KDevelop. Try creating a new session. If that doesn't help, try deleting (or renaming/moving) all KDevelop's settings, caches.
(In reply to Igor Kushnir from comment #7) > (In reply to Artur from comment #6) > > Nope, cold start on the same _empty_ project on the next day - 10 seconds, > > then 2 sec! It's a death for any coder. > > Just have tried QT Creator, and actually it is a really great IDE! Open any > > C++ code without creating a project and it will complete _any_ piece of a > > code in a nanosecond! There are no seconds, but picoseconds maybe. It will > > be the best autocomplete mechanism for KDevelop. > My recent experience is the opposite. Qt Creator's completion for a > medium-sized project used to be satisfactory. It still froze occasionally, > but so does KDevelop's completion. There seemed to be a memory leak in Qt > Creator's clangd triggered by switching back and forth between project > configurations. After a recent update to Qt Creator 8, performance became so > horrible that I was forced to disable clangd and use Qt Creator's deprecated > internal code model fallback, which is less accurate but much faster and > memory-efficient. > > Lately I rarely experience completion slowness in KDevelop. Try creating a > new session. If that doesn't help, try deleting (or renaming/moving) all > KDevelop's settings, caches. Thanx for sharing, but no.. Everyone say KDev is a turtle in autocompletion even with delay on 100ms. And we ate it anyway. It is a great IDE, but it is a big whole of a bugs too. The problem actually is in a "cache", sometimes it breaks everything and it needs to be cleared. It says: ` kdevelop.plugins.clang: Failed to parse : %path_to_file clang_parseTranslationUnit2 return error 4 start KDevelop with KDEV_CLANG_DISPLAY_DIAGS=1 ` And this actually emits cache clearing (as I understand) and helps to fix it. I'm already tired to fight with this and can clear it on start by default every time. The best workaround will be something like this: ` alias kdev='rm -r .cache/kdevelop/ && kdev' ` So how to properly clear-it-fully to reset the parser state?
(In reply to Artur from comment #8) > The best workaround will be something like this: > ` > alias kdev='rm -r .cache/kdevelop/ && kdev' > ` > > So how to properly clear-it-fully to reset the parser state? There is also .cache/kdevduchain. There are many kdev* data directories in ~/.local/share. And ~/.config/kdeveloprc.
(In reply to Igor Kushnir from comment #9) > (In reply to Artur from comment #8) > > The best workaround will be something like this: > > ` > > alias kdev='rm -r .cache/kdevelop/ && kdev' > > ` > > > > So how to properly clear-it-fully to reset the parser state? > There is also .cache/kdevduchain. There are many kdev* data directories in > ~/.local/share. And ~/.config/kdeveloprc. "There are many" Can You give a concrete answer? I don't want to delete '~/.config/kdeveloprc' and don't know anything about data in these directories.
Did you try creating a new session? (In reply to Artur from comment #10) > "There are many" > Can You give a concrete answer? I don't want to delete > '~/.config/kdeveloprc' and don't know anything about data in these > directories. So move/rename them. I don't know what would help, if anything. Maybe something in your project triggers a bug in KDevelop. My computer specs are way lower than yours and completion delays are rare lately. Too many open files slows everything down, so I close them all when something feels slow.
(In reply to Igor Kushnir from comment #11) > Did you try creating a new session? > > (In reply to Artur from comment #10) > > "There are many" > > Can You give a concrete answer? I don't want to delete > > '~/.config/kdeveloprc' and don't know anything about data in these > > directories. > So move/rename them. I don't know what would help, if anything. Maybe > something in your project triggers a bug in KDevelop. My computer specs are > way lower than yours and completion delays are rare lately. Too many open > files slows everything down, so I close them all when something feels slow. "way lower than yours" My cpu limits on 800 MHz on boot. There is no matter what cpu speed do You have - it's obviously slow. "Too many open" I said before - 1 (ONE, UNO) file. Now I see segmentation fault. So no help.. Will give it a one more chance moving unknown even for devs dirs. Thanks anyway.
> kdevelop.plugins.clang: Failed to parse : %path_to_file This actually may be a packaging problem. Do you know which libclang version is used by your KDevelop?
(In reply to Gleb Popov from comment #13) > > kdevelop.plugins.clang: Failed to parse : %path_to_file > > This actually may be a packaging problem. Do you know which libclang version > is used by your KDevelop? Already tried AppImages from KDE site. So, sometimes it works, and now is not. rm -r .cache/kdev* doesn't fix it. Also, it prints lines like: `No context found for QUrl ... *.hpp` `.. plugins.definesandincludes: error while fetching includes for "clang"... Foundd candidate GCC....` Clang 14.06-2 from Arch repos installed. Nothing more and it tries to use it.
(In reply to Artur from comment #14) > (In reply to Gleb Popov from comment #13) > > > kdevelop.plugins.clang: Failed to parse : %path_to_file > > > > This actually may be a packaging problem. Do you know which libclang version > > is used by your KDevelop? > > Already tried AppImages from KDE site. > So, sometimes it works, and now is not. > > rm -r .cache/kdev* doesn't fix it. > > Also, it prints lines like: > `No context found for QUrl ... *.hpp` > `.. plugins.definesandincludes: error while fetching includes for "clang"... > Foundd candidate GCC....` > > Clang 14.06-2 from Arch repos installed. Nothing more and it tries to use it. OK, we have figured it out. Parser breaks often and it's ok for KDE projects. To fix it on a day or a week, who knows, You should create new project and move Your files there. Parser will work for a... some time may be we don't know yet. Stupid bugs, more bugs and only bugs. But everytime there are people who can say "no it works for me, it's super fast, I don't know what are You talking about". And it's a dev oh my god! Thanks for help anyway. You can close this bug now...
(In reply to Artur from comment #15) > (In reply to Artur from comment #14) > > (In reply to Gleb Popov from comment #13) > > > > kdevelop.plugins.clang: Failed to parse : %path_to_file > > > > > > This actually may be a packaging problem. Do you know which libclang version > > > is used by your KDevelop? > > > > Already tried AppImages from KDE site. > > So, sometimes it works, and now is not. > > > > rm -r .cache/kdev* doesn't fix it. > > > > Also, it prints lines like: > > `No context found for QUrl ... *.hpp` > > `.. plugins.definesandincludes: error while fetching includes for "clang"... > > Foundd candidate GCC....` > > > > Clang 14.06-2 from Arch repos installed. Nothing more and it tries to use it. > > OK, we have figured it out. > Parser breaks often and it's ok for KDE projects. > To fix it on a day or a week, who knows, You should create new project and > move Your files there. Parser will work for a... some time may be we don't > know yet. > Stupid bugs, more bugs and only bugs. But everytime there are people who can > say "no it works for me, it's super fast, I don't know what are You talking > about". And it's a dev oh my god! > > Thanks for help anyway. You can close this bug now... Hahaha) Oh.. world. It's broken again ) Ok, it's pointless.
Glad you found a different project that works better for you.
(In reply to Artur from comment #16) > Hahaha) Oh.. world. > It's broken again ) > Ok, it's pointless. Being sarcastic and salty does not help. If you want issue to be fixed you have to do some work and provide reproduction steps or other requested information, perform debugging or performance profiling (if you're able to do that), etc. If you don't want to help, just move along. In both cases there is no need for words such as yours. We're all volunteers here and do our work for fun and own pleasure.