Registered Member
|
Hello,
Let me start by stating that I think Kdevelop is the best IDE out there. But Kdevelop5 parsing is so slow I cannot work with it anymore. Auto-complete takes for ever to kick in (sometimes minutes) and I'm running it with 8 threads on 4 cores with 16Gb of RAM... Even on simple programs it is not that fast. I've been parsing this :https://github.com/MalcolmMielle/BetterGraph. Which goes relatively fast but it's still a couple of seconds (like 10) before the autocompletion kicks in... I miss Kdevelop 4 parsing, is there anyway to revert to it ? EDIT: Just realise that when I put 500ms for the parser to kick in and press enter Kdevelop fix the number of thread back to 2... So I might be limited to 2 threads... Why is that ? After checking htop yes, it seems kdevelop is limited to 2 threads max... This was testing with Kdev5.2.1 on Fedora 27 and Gentoo and on two different machines |
Global Moderator
|
Do you invoke completion in .cpp or in .h files? In .cpp it should be fast, I'm aware of a bug with slowness in .h...
I'm working on the KDevelop IDE.
|
Registered Member
|
I did on both.
When I looked at the number of processes on htop named Kdevelop I always only have 2 :/. Any better way to test that the background parser is behaving the way it should ? EDIT: ok just realised that's probably the process named kworkers... and then there is the good number... Maybe it is coming from the fact that my hpp files are pretty big. Anyway to optimize the speed of the parser. I really miss the old one for it gave me instantaneous autocomplete on the same exact project.
Last edited by mmielle on Sat Feb 10, 2018 5:56 pm, edited 1 time in total.
|
Global Moderator
|
Parallel parsing will not help with this problem anyways. Each individual compilation unit is processed single-threaded, it only helps if you need to analyze more than one, which is not the case for completion. So let's rather look for why completion is so slow.
Can you try with the AppImage from kdevelop.org/download? Can you give a link to the project you use it with and tell me where you invoke completion and how long it takes for you?
I'm working on the KDevelop IDE.
|
Registered Member
|
Alright so for testing right now I did not take the worst offender and went for this project VoDiGrEx. I wait for the whole project to be parsed (which takes quite a while) and then I go into the file named MultipleLineFollowerKeypoints.hpp. Then I went line 85 and just entered `this->` and then directly pressed Ctrl-Space. It took 9 seconds for the auto-complete to kick in and propose stuff to me . Before I got the typing suggestions only.
That is using the AppImage. |
Global Moderator
|
Ok, for .h files I can kind of understand it, that is a limitation of clang currently unfortunately. It happens if you have lots of includes because they are reparsed each time.
Does it happen in .cpp files as well?
I'm working on the KDevelop IDE.
|
Registered Member
|
Hi! Unfortunately, the same issues here: in all my projects (100% C/C++), I link libraries like OpenGL & Co., OpenCV, Eigen, .. and some my libraries, but with KDevelop 5.2.1. the auto completion is slow and very often does not work at all, while the background parser is very slow but, after a while, it does not resolve most of the dependencies ...
All my projects are fully CMake based, and I have no problem to compile them. I'm still using KDevelop 4.3, that I simply consider one of the best IDE out there: the auto completion it does not always work perfectly, but when it works it's simply the best in my opinion, fast and complete. I gave a chance to all versions of KDevelop 5, but every time I have to come back to 4.3. Alberto |
Registered Member
|
Hello, i have similar problems with finding system libraries, most of them are marked as "not found" by KDevelop while they were installed and project is able to compile and run perfectly.
The workarround i use to fix this is to chenge "Compiler for path" from "Clang" to "GCC" in "Project configuration > Language support > C/C++ Parser" |
Registered Member
|
It seems to work fine in a small cpp that I tried. I would have to try a bigger one to make sure but I don't have that 9 seconds delay.
I'm so sorry to hear this as I work with Eigen, OpenCV, PCL and ROS, so I guess Kdevelop5 is not going to work for me. 9 seconds when only openCV is included and it's a lot worst when other libraries are there... It feels like clang is not really ready... Is there any way to get back the old parser... ? It worked wonders (apart from Eigen . Or any way to get something like the Kdevelop4 AppImage that works for Fedora27? Or version of Kdevelop4 that I can build against qt5 libraries ? At this point I just want my working tool working again :3 |
Global Moderator
|
Yes please try a bigger file. It should work in cpp files, because there clang will include everything else in the precompiled preamble and then it's very quick. As said, in header files this mechanism sadly does not work at all, and thus if you have lots of includes (also recursively) it will be slow. I think clang is planning some "modules" framework I didn't look at in detail, which will eventually improve this situation in the forseeable future.
The old parser was borderline unmaintainable even for the C++03 standard, and for 17 it would be completely impossible, and I mean that. The problem is that nowadays also the standard library etc. use the new standards, so I guess using the old parser won't be much fun ...
You can install qt4 and build kdevelop against that. The old parser was never ported to $thing 5 afaik.
I'm working on the KDevelop IDE.
|
Global Moderator
|
Yes, this is a strange bug somebody needs to investigate. I'm quite confused by it.
I'm working on the KDevelop IDE.
|
Registered Member
|
I get a 11 seconds before auto-completion kicks in on a cpp file. I use this project, in th src file named "ACG.cpp". I go line 153 and enter `landmarkObservation->` and the autocomplete kicked in after 11seconds.
|
Registered Member
|
As some sort of question the c++ parser of Juci++ (https://github.com/cppit/jucipp) seem to be based on clang also and go blasingly fast for me. What is the difference between the this and kdevelop ?
|
Global Moderator
|
I don't know. I see they use ctags as well, maybe that is quick? But really, in KDevelop it's quick as well in .cpp files. That it is slow in .h files is afaik a bug in clang, and I would be surprised if another application using the same API would not have the same problem.
But if you can name some example location where jucipp is fast for you while kdevelop is slow, I'd be more than happy to try it and eventually find out what's up!
I'm working on the KDevelop IDE.
|
Registered Member
|
I would love that too, sadly I have no experience with clang and as to why that is :/. But if I ever gets a hint I would definitely let you know. Maybe it has to do with their cpp wrapper onto clang also (https://github.com/cppit/libclangmm/)
|
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, Sogou [Bot]