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

[Mike Jackson]

I have been using the nightlies and the time to open our project 
(DREAM.3D) is getting better but still can induce a spinning beach ball 
on my macOS 10.10 machine (12 Core Xeon with SSD).

One of the issues that I wanted to make sure that you are also seeing is 
the "Multiple Targets" issue where we get executables that are numbered 
like DREAM3D,DREAM3D2,DREAM3D3.

There is also an issue with multiple "Source Directory" and "Build 
Directory" showing up in each target in the projects view. I have a 
feeling that some of this may be how we are using CMake? Our project as 
a whole ends up having multiple "project(...)" invocations. Also is 
there an implicit assumption the for each "CMakeLists.txt" is a project? 
In our plugins we use CMakeLists.txt files BUT they do not have a 
"project()" call in them and they are included with "include()" instead 
of "add_subdirectory()" which might make a difference.

Thanks for moving the CMake integration forward.
-- 
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jackson at bluequartz.net


Tobias Hunger wrote:
> Hi Mike,
>
> I found a couple of optimization opportunities. Let's see how much
> difference these will make:-)
>
> Some smaller ones are in already, but the big one (finding CMakeLists
> again after they were inserted) is still open.
>
> On Fri, Mar 24, 2017 at 4:43 PM, Mike Jackson<imikejackson at gmail.com>  wrote:
>> 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
>>