Oh, I though it will use multiple threads to compile the same file but it seems
it uses multiple instances to compile multiple files, what make -j and ninja
already do...
BogDan.
On January 6, 2019 8:20:32 PM GMT+02:00, BogDan Vatra via Qt-creator
<qt-creator@qt-project.org> wrote:
>Hi,
>
>It's not QtCreator fault, it's clang which can't compile fast enough
>your file. The only hope for a faster clang code model is this
>https://reviews.llvm.org/D52193 patch. IMHO TQC and everyone who uses
>clang code model should do everything they can to help, review and
>merge that patch.
>
>Cheers,
>BogDan.
>
>
>On January 6, 2019 7:55:41 PM GMT+02:00, 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 on behalf of
>>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
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator
