Re: [cmake-developers] CMake 3.5 generation time

2016-02-08 Thread Brad King
On 02/05/2016 10:16 AM, Brad King wrote: > It looks like these methods: > > cmGlobalGenerator::FindTargetImpl > cmGlobalGenerator::FindGeneratorTargetImpl > cmGlobalGenerator::FindImportedTargetImpl > > are all now using linear searches instead of algorithmically > efficient data structures

Re: [cmake-developers] CMake 3.5 generation time

2016-02-06 Thread Stephen Kelly
Bartosz Kosiorek wrote: > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f The relevant part of that patch (from the point of view of separating configure time code from generate time code) is the removal of the use of TotalTargets at generate time. Mappings could be re-introduced

Re: [cmake-developers] CMake 3.5 generation time

2016-02-05 Thread Brad King
On 02/05/2016 09:10 AM, Bartosz Kosiorek wrote: > Finally I was able to finalize git bisect. > Generally without regression time was: real3m44.070s > first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] > cmGlobalGenerator: Remove direct storage of target > time increased to real

Re: [cmake-developers] CMake 3.5 generation time

2016-02-05 Thread Bartosz Kosiorek
Hi. Finally I was able to finalize git bisect. Generally without regression time was: real 3m44.070s first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] cmGlobalGenerator: Remove direct storage of target time increased to real6m36.929s (second clean run real6m12.635s)

Re: [cmake-developers] CMake 3.5 generation time

2016-02-05 Thread Brad King
On 02/04/2016 05:57 PM, Bartosz Kosiorek wrote: > Unfortunately after building locally, the times are totally different (worse). Check CMAKE_BUILD_TYPE in the CMakeCache.txt file of your CMake build and make sure it is "Release". If not, just change it and run "make" again to rebuild. Thanks,

Re: [cmake-developers] CMake 3.5 generation time

2016-02-04 Thread Bartosz Kosiorek
Hi Brad Unfortunately after building locally, the times are totally different (worse). I don't know why it is happen. Builds for some specific commits, are not able to run properly. In that case I have just skip bisect commit. Do you have some further recommendation? On master the times are:

Re: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!)

2016-02-04 Thread Brad King
On 02/04/2016 07:09 AM, Bartosz Kosiorek wrote: > There is huge difference in Unix Makefile generation time between > 32 vs 64 bit cmake version: > > 32 bit CMake 3.5.0 generation time: > real5m33.310s > user5m27.268s > sys0m3.540s > > 64 bit CMake 3.5.0 generation time: > real

Re: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!)

2016-02-04 Thread Bartosz Kosiorek
Hi Brad. I'm configuring/generating NavKit project, by using -G "Unix Makefiles" parameter. I downloaded cmakes from website: https://cmake.org/download/ All generation were done on clean output (deleted all files generated by cmake) on the same repository version, in the same directory. The

Re: [cmake-developers] CMake 3.5 generation time

2016-02-04 Thread Brad King
On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: > I downloaded cmakes from website: > https://cmake.org/download/ > > All generation were done on clean output (deleted all files generated by > cmake) > on the same repository version, in the same directory. > The only difference was cmake version

Re: [cmake-developers] CMake 3.5 generation time

2016-02-04 Thread Bartosz Kosiorek
Hi. I would like to mention that all my previous times, was measured for clean Generation (I deleted all generation files) I will try to make bisect build, to check where regression occur. Now I would like to present results with enabled cleaning only on first run: CMake 3.4.3 Unix Makefile