[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 <gang65 at poczta.onet.pl>:

> 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 <brad.king at kitware.com>:
>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160204/1263c423/attachment.html>