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 <imikejack...@gmail.com> wrote: > Tobias Hunger wrote: >> >> On Fri, Mar 24, 2017 at 2:04 PM, Mike Jackson<imikejack...@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 > _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
