[Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Mike Jackson]

Tobias Hunger wrote:
> On Fri, Mar 24, 2017 at 2:04 PM, Mike Jackson<imikejackson at gmail.com>  wrote:
>>> Well, server-mode does get way better information out of cmake, so
>>> that is kind of expected:-)
>>>
>>> What does the code model say (Tools>C++>Inspect C++ code model)? Does
>>> it list the expected include directories?
>>
>> I just noticed that the issue is when I look at a .h file in the editor. In
>> the project list the .h file is grayed out and the code model only shows a
>> few include paths. Its like the Project Model does not know how to handle
>> the .h files because they are not compiled?
>
> That should not make any difference: Those header files are not ever
> passed on to the code model:-) That just gets the sources and include
> paths and then figures stuff out itself.
>
>>> I want to get rid of the tealeaf mode as soon as possible. The name is
>>> fitting: What Creator is doing without server-mode is reading in tea
>>> leaves, mostly tea leaves that are documented to change meaning at any
>>> time!
>>>
>>> Perpetuating tealeaf mode by having users enable it for newer cmakes
>>> is definitely not in my interest!
>>
>> I agree philosophically but there may be a practical side of things. Lets
>> see if the issues all get fixed by release of QtCreator 4.3 then I really
>> will not have any argument at that point.
>
> I do not find anything to fix: DREAM.3D opens in<  5s for me.
>
> A couple seconds later (for C++ parsing, Test scanning, etc.) the CPU
> usage is down to below 5% on all cores.
>
> Ninja reports only 1351 things that need building though, so maybe I
> did something wrong?

I tried again with build -997 and it does seem much faster now. I wonder 
what changed between -992 and -997. Do you still see multiple "DREAM3D" 
targets on the list? I see DREAM3D, DREAM3D2, DREAM3D3 and a few other 
targets within the main project show up like that.

>
>>> I'm currently trying to set up DREAM.3D for testing:-)
>>>
>>> So far I found two smaller issues with creator's cmake support due to
>>> it -- and I did not even manage to make it build yet:-) What a
>>> wonderful test project!
>> Interesting. What were the issues? If you do find issues with DREAM.3D or
>> any of its subprojects just let us know or put in an issue at GitHub.com.
>> Our use of CMake may not be completely standard or may be unexpected. Some
>> of the CMake code has been in there since 2009.
>
> Small stuff inside Creator. E.g. Creator should *always* show at least
> the top level CMakeLists.txt file and a broken configuration of
> DREAM.3D broke that. Fixed now.
>
> <snip>
>>> Well, cmake is heavily single-threaded, so all your cores will not
>>> help with anything cmake-related:-)
>> So when QtCreator is spinning a beach-ball on macOS and QtCreator is only
>> burning 100% is that because CMake is taking a while to do something?
>
> No idea:-)
>
> What does the progress bar say when creator is busy? That should give
> a hint as to what is going on. As I said: It takes about 5s to open
> DREAM.3D on my laptop and that is a considerably less capable machine
> than yours.

The beach-ball really prevents anything from being seen. Nothing obvious 
that I can see. Is it possible to output something to the "Application 
Output" or "Compile Output" widgets that indicates that information is 
being gathered from CMake? Or maybe there is a way for me to log that 
and I just don't know about it (Most likely..).
>
>> Configuring our project can take upwards of 30 seconds on macOS and Linux
>> and even longer on Windows. You can check the times at
>> http://my.cdash.org/index.php?project=DREAM3D, clicking the gear icon in the
>> upper right side and selecting Advanced View.
>
> I must be doing something wrong then, my machine is much faster than that.

Are you on Linux? Our Core i7-4790K (4.0GHz) will configure in 7 
seconds. The same exact configuration on my 2010 12 core Mac Pro take 41 
secs.

>
>> Maybe popping up a dialog if it is taking longer than xx seconds to run the
>> CMake part? That way it does not look like it is hung up? I imagine for
>> smaller projects this is not a problem because CMake runs fast enough on
>> those projects.
>
> I do not think that cmake is the problem here. You know how long it
> takes to run cmake on the command line and Creator should never be
> slower than that.
>
> Best Regards,
> Tobias

I agree (and proved that is the case) it is after cmake is done running 
when the project tree is being generated that is taking the most time. 
I'll try to get over to the Linux machine and see how long it takes over 
there.

Mike Jackson