Re: [cmake-developers] CMake 3.5 generation time

[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 like before.

This should fix it:

 Fix internal target lookup performance regression
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6cbf6a51

 Improve internal generator target structure lookup
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b7d5871

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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 in cmGlobalGenerator, maybe with names 
indicating that their purpose is faster searching, and separated between 
cmTargets and cmGeneratorTargets:

 TargetMap TargetSearchIndex;
 TargetMap ImportedTargetSearchIndex;
 GeneratorTargetMap GeneratorTargetSearchIndex;

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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 real6m36.929s (second clean run real6m12.635s)
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f
> 
> In our project we have exactly 3287 targets, because we have
> flavored builds (in many cases one source code is build in
> three variants, depending on map type)

Thanks.  That commit was part of a larger refactoring topic:

 Merge topic 'use-generator-target'
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1e8c920d

and so cannot be simply reverted without a lot of other changes.

It looks like these methods:

 cmGlobalGenerator::FindTargetImpl
 cmGlobalGenerator::FindGeneratorTargetImpl
 cmGlobalGenerator::FindImportedTargetImpl

are all now using linear searches instead of algorithmically
efficient data structures like before.  These lookups are done
a lot.

Steve, IIUC you made this change as part of refactoring to
separate configure-time and generate-time structures.  We need
to fix this to make the lookups efficient again.  Where should
we store the needed data structures now?

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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)
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f

In our project we have exactly 3287 targets, because we have flavored
builds (in many cases one source code is build in three variants, depending
on map type)

Below there is an logs from git bisect and times for specific commits.


0c97d32f7a592a768d614c19b3fd48eab245a2c4 is the first bad commit
commit 0c97d32f7a592a768d614c19b3fd48eab245a2c4
Author: Stephen Kelly 
Date:   Sun Oct 25 12:22:51 2015 +0100

cmGlobalGenerator: Remove direct storage of targets

Find the target by looping when needed.

:04 04 81eb745e29adced1b44b4e58e6f7658691ff0613
fe0617270fc29a9dabf64035f5a1b3827413bb36 M Source



Bisection logs:
git bisect log
git bisect start
# bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version
update
git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50
# good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3
git bisect good 0aef6f2412177a236deb292654402518777f3cb0
# skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic
'vs-show-def-files'
git bisect skip 49ac682d39af7fe47e79455827e2e83130193236
# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa
# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e
# skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic
'cpack-deb-compression-scheme-test'
git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e
# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff
# skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic
'use-generator-target'
git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45
# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
git bisect good cf69630e510a5c639a93a99b315fcefea9688935
# skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return
actual error when a package is not found (#15810)
git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb
# skip: [c389f8bb07e900d805ca3163f47b06e3dbe4303b] cmLocalGenerator: Port
Find method away from GetGeneratorTarget
git bisect skip c389f8bb07e900d805ca3163f47b06e3dbe4303b
# skip: [1a8c7bc2c649781d1163c1966245a45e0fb829ba] libarchive
3.1.2-601-g3bfe5f1 (reduced)
git bisect skip 1a8c7bc2c649781d1163c1966245a45e0fb829ba
# skip: [60cbd9b9da2059481e2f29fbb5859a5b0643d3d7] CMake Nightly Date Stamp
git bisect skip 60cbd9b9da2059481e2f29fbb5859a5b0643d3d7
# bad: [3cb726371f27948149f668d43aa58cd2a5e9be4c] Merge topic
'wix-toplevel-feature-required'
git bisect bad 3cb726371f27948149f668d43aa58cd2a5e9be4c
# good: [6a56c8247fa874bd418c3e175c941070dafb0e76] Tests: Disable parallel
test execution while running ctest_test
git bisect good 6a56c8247fa874bd418c3e175c941070dafb0e76
# skip: [e14709e5a5379f0a6fa2434551211b66561ad540] Merge topic
'revert-autorcc-qt-5.1'
git bisect skip e14709e5a5379f0a6fa2434551211b66561ad540
# good: [832fe4b133f47781f4e08df1f83fdc4e3e7aa06b] libarchive: Fix VS 7.1
Debug build
git bisect good 832fe4b133f47781f4e08df1f83fdc4e3e7aa06b
# skip: [b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d] Merge topic
'autorcc-qt-5.1-compat'
git bisect skip b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d
# good: [91a829c165209b96c20d17f8eb7d46d3375cc57c] Makefiles: Remove unused
variable
git bisect good 91a829c165209b96c20d17f8eb7d46d3375cc57c
# skip: [5cdba31fc631453d530abbac04bf4a455d1f10bb] Merge topic
'cpack-osx-sysroot'
git bisect skip 5cdba31fc631453d530abbac04bf4a455d1f10bb
# skip: [6c0d8a5d027bfe681f45337c79d1bbba6331bbd8] README: Fix typo in
wording
git bisect skip 6c0d8a5d027bfe681f45337c79d1bbba6331bbd8
# bad: [4ce9742ae33678d8fce189d172c2fffb1a43061c] Alias: Fix access at
generate-time (#15832)
git bisect bad 4ce9742ae33678d8fce189d172c2fffb1a43061c
# good: [85e0bb84f5eca2f77f070bce9f83024854096307] libarchive: Avoid using
'uint8_t' as bitfield type
git bisect good 85e0bb84f5eca2f77f070bce9f83024854096307
# skip: [13dc7bdb5e3a0eaaf3607b154bba77a01404a788] CMake Nightly Date Stamp
git bisect skip 13dc7bdb5e3a0eaaf3607b154bba77a01404a788
# skip: [a375702eaa961a496b9420a836c336d884e9cbf3] CMake Nightly Date Stamp
git bisect skip a375702eaa961a496b9420a836c336d884e9cbf3
# good: [593f347b5385a510e641eca0448f7ddf64c1c12b] VS7: Port some
implementation details to cmGeneratorTarget
git bisect good 593f347b5385a510e641eca0448f7ddf64c1c12b
# skip: [7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a] Merge topic
'bootstrap-cleanup'
git bisect skip 7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a
# skip: 

Re: [cmake-developers] CMake 3.5 generation time

[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,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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:
real 8m1.255s
user 7m56.684s
sys 0m3.900s

Bisection logs:
git bisect log
git bisect start
# bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version
update
git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50
# good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3
git bisect good 0aef6f2412177a236deb292654402518777f3cb0
# skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic
'vs-show-def-files'
git bisect skip 49ac682d39af7fe47e79455827e2e83130193236
# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa
# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e
# skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic
'cpack-deb-compression-scheme-test'
git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e
# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff
# skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic
'use-generator-target'
git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45
# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
git bisect good cf69630e510a5c639a93a99b315fcefea9688935
# skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return
actual error when a package is not found (#15810)
git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb


Bisection results:
# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
real 3m52.078s
user 3m47.508s
sys 0m4.240s

# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
real 12m6.370s
user 12m2.872s
sys 0m4.392s

# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
real 3m54.556s
user 3m44.596s
sys 0m4.284s

# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
real 12m36.866s
user 12m31.864s
sys 0m4.348s

# good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port
implementation to cmGeneratorTarget.
git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e
1. First clean generation
real 3m40.716s
user 3m34.908s
sys 0m3.944s
2. Second clean generation
real 3m41.351s
user 3m36.880s
sys 0m3.872s


2016-02-04 20:56 GMT+01:00 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 generation
> 1. Clean run (rm -rf Output)
> real 1m31.233s
> user 1m26.136s
> sys 0m3.004s
> 2. Dirty run (no deletion)
> real 1m27.101s
> user 1m24.620s
> sys 0m2.988s
> 3. Dirty run (no deletion)
> real 1m26.237s
> user 1m23.240s
> sys 0m3.020s
> 4. Dirty run (no deletion)
> real 1m27.670s
> user 1m24.764s
> sys 0m2.816s
>
> CMake 3.5.0-rc1 Unix Makefile generation
> 1. Clean run (rm -rf Output)
> real 2m34.244s
> user 2m30.176s
> sys 0m3.220s
> 2. Dirty run (no deletion)
> real 2m35.259s
> user 2m32.400s
> sys 0m3.116s
> 3. Dirty run (no deletion)
> real 2m27.881s
> user 2m25.184s
> sys 0m3.032s
> 4. Dirty run (no deletion)
> real 2m25.139s
> user 2m22.552s
> sys 0m2.984s
>
> 2016-02-04 18:57 GMT+01:00 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 used for configuring.
>> >
>> > How I could check what was caused such long times?
>>
>> Try also timing the second and third runs on a single build tree
>> to get timings without all the platform introspection tests.
>>
>> You could clone the CMake Git repository, build from source with
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a
>> profiler (e.g. valgrind --tool=callgrind).  Alternatively you
>> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there
>> is a small range of commits that causes the regression.  That
>> could really help narrow it down.
>>
>> Thanks,
>> -Brad
>>
>>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake 

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

[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:
> real2m36.457s
> user2m32.008s
> sys0m3.184s
> 
> Unfortunately there no 64bit CMake version for Windows:
> https://cmake.org/download/
> 
> Is it possible to create 64 bit build for Windows?

Perhaps eventually, but please try running those timings with local
builds of CMake on Windows to see if the difference carries across
platforms.

> 64bit cmake 3.5.0-rc1 Makefile Generation
> 1. Run
> real2m36.457s
> user2m32.008s
> sys0m3.184s
> 2. Run
> real2m36.764s
> user2m31.672s
> sys0m3.296s
> 
> 64bit cmake 3.4.3 Makefile Generation
> 1. Run
> real1m29.679s
> user1m24.696s
> sys0m2.920s
> 2. Run
> real1m28.266s
> user1m24.220s
> sys0m2.976s

There has been some refactoring but it has not had that effect on
projects I've seen.  What project are you configuring?  Were both
of these versions built the same way?  Is this consistent when
configuring, say, CMake itself?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[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 only difference was cmake version used for configuring.

How I could check what was caused such long times?

Best Regards
Bartosz



2016-02-04 14:30 GMT+01:00 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:
> > real2m36.457s
> > user2m32.008s
> > sys0m3.184s
> >
> > Unfortunately there no 64bit CMake version for Windows:
> > https://cmake.org/download/
> >
> > Is it possible to create 64 bit build for Windows?
>
> Perhaps eventually, but please try running those timings with local
> builds of CMake on Windows to see if the difference carries across
> platforms.
>
> > 64bit cmake 3.5.0-rc1 Makefile Generation
> > 1. Run
> > real2m36.457s
> > user2m32.008s
> > sys0m3.184s
> > 2. Run
> > real2m36.764s
> > user2m31.672s
> > sys0m3.296s
> >
> > 64bit cmake 3.4.3 Makefile Generation
> > 1. Run
> > real1m29.679s
> > user1m24.696s
> > sys0m2.920s
> > 2. Run
> > real1m28.266s
> > user1m24.220s
> > sys0m2.976s
>
> There has been some refactoring but it has not had that effect on
> projects I've seen.  What project are you configuring?  Were both
> of these versions built the same way?  Is this consistent when
> configuring, say, CMake itself?
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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 used for configuring.
> 
> How I could check what was caused such long times?

Try also timing the second and third runs on a single build tree
to get timings without all the platform introspection tests.

You could clone the CMake Git repository, build from source with
-DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a
profiler (e.g. valgrind --tool=callgrind).  Alternatively you
could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there
is a small range of commits that causes the regression.  That
could really help narrow it down.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.5 generation time

[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 generation
1. Clean run (rm -rf Output)
real 1m31.233s
user 1m26.136s
sys 0m3.004s
2. Dirty run (no deletion)
real 1m27.101s
user 1m24.620s
sys 0m2.988s
3. Dirty run (no deletion)
real 1m26.237s
user 1m23.240s
sys 0m3.020s
4. Dirty run (no deletion)
real 1m27.670s
user 1m24.764s
sys 0m2.816s

CMake 3.5.0-rc1 Unix Makefile generation
1. Clean run (rm -rf Output)
real 2m34.244s
user 2m30.176s
sys 0m3.220s
2. Dirty run (no deletion)
real 2m35.259s
user 2m32.400s
sys 0m3.116s
3. Dirty run (no deletion)
real 2m27.881s
user 2m25.184s
sys 0m3.032s
4. Dirty run (no deletion)
real 2m25.139s
user 2m22.552s
sys 0m2.984s

2016-02-04 18:57 GMT+01:00 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 used for configuring.
> >
> > How I could check what was caused such long times?
>
> Try also timing the second and third runs on a single build tree
> to get timings without all the platform introspection tests.
>
> You could clone the CMake Git repository, build from source with
> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a
> profiler (e.g. valgrind --tool=callgrind).  Alternatively you
> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there
> is a small range of commits that causes the regression.  That
> could really help narrow it down.
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers