Hi Michael, if we add more threads we will waste more memory and the code
complexity goes up too. I don't work on this code anymore but there will be
always trade offs between speed, memory and code complexity (which increases
maintenance time and reduces new feature time). So you want to do the
diagnostic generation only if there it's nothing else to do? You can write a
suggestion for it and find many people who vote for it or even better you give
us some money so we can hire a guy who will work on it. ;-) We want to improve
our C++ support much faster too but we are only a very small team.
Best regards, Marco
On January 6, 2019 19:04:47 Michael Jackson <mike.jack...@bluequartz.net> wrote:
On some points I agree, but being on macOS my choices are pretty limited for an
IDE. xCode? Uh no. Eclipse? No way. What else is there? QtCreator is pretty
much the only choice I have. I am hoping that the QtCreator team can carve out
some time in 2019 to look into some of the speed issues with the clang backend.
Frankly my issue with the old parser was _because_ of boost. The original code
model would _never_ want to parse our use of boost which made code completions
pretty non-existent in our boost heavy code. When the CCM successfully parses
the file the complete is spot on, it just takes forever to parse the code. One
thing that I have noticed is that if I turn off all the clang-tidy and clazy
checks then the speed on first opening is pretty decent (I’m on a 2012 Mac Pro
with dual Xeon so not the fastest CPUs in the world). If I turn on the
clang-tidy checks that I want then the time to get even the function list is
abysmal. I would think a 2 stage parse of the file might work better with 2
threads: 1 for the initial parser and one for the clang-tidy checks. Waiting 30
seconds (or sometimes never) for a function list to appear seems like a
deficiency in my mind.
Again, I really appreciate how far QtCreator has come from the “old days” in
the 2.x versions. I have used it through the 1.5 years of “dark ages” where
debugging on macOS was basically non-existent due to LLDB being so immature.
QtCreator works way better with our CMake heavy projects and all of the
external libraries that we used. I think it just needs some polish on the CCM
parsing and reaction times put into it in 2019.
--
Michael Jackson | Owner, President
BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
On 1/4/19, 8:20 PM, "Qt-creator on behalf of NIkolai Marchenko"
<qt-creator-boun...@qt-project.org<mailto:qt-creator-boun...@qt-project.org> on
behalf of enmarantis...@gmail.com<mailto:enmarantis...@gmail.com>> wrote:
Qt creator is rapidly becoming a source of major annoyance ever since clang
code model was introduced.
It's slow, sometimes taking 30+ seconds to react to F2
What's worse, it reacts to it once you gave up and navigated somewhere manually
and makes you suddenly type stuff in plces you won't expect.
It's buggy, fails on boost and fails to produce a highlight on everything that
depends on it
It's too easy to break, A single symbol it doesn't detect breaks highlighting
and hint for the whole file chain, whether stuff later down the line requires
that symbol or not.
While I understand the desire to stop reimplementing the wheel with code
parser, the Clang Code Model made Qt Creator strictly worse for any complex
project to the point I catch myself wanting to use something else on a regular
basis. This wasn't the case ever before CCM was introduced.
_______________________________________________ Qt-creator mailing list
Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator
