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 <gan...@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.k...@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 >> >> >
-- 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