A round of performance improvements to generate time was done as part of CMake 3.11 and that significantly helped. What would be helpful is a performance analysis run of CMake itself to determine if the issue is that we are IO bound ( and need to do multi-threaded writes ) or compute bound.
While this information will be project dependent, it would be great to start getting samples from the community. On Wed, Mar 20, 2019 at 1:53 PM J. Caleb Wherry <[email protected]> wrote: > > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native C++, > Managed C++, C#, Java, CUDA, etc) and the majority of the time for the > configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the > project files and filters for each C++ project (the majority of our projects) > for VS generators (what we use). I'm just looking to see if there is anything > to look at or potentially speedup up the generate step besides "get a faster > drive". > > Thanks! > -Caleb > > On Thu, Nov 17, 2016 at 11:15 AM Damian <[email protected]> wrote: >> >> Hi all, >> >> We are still in the process of switching our large Make-based build to >> CMake. One of the issues we're running into is the time it takes to reparse >> and regenerate the CMake project (whether ninja, VS, or make) after touching >> any CMake file. To give you an idea, we have about 1000 targets and that >> takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or do >> a better job regenerating only what needs regenerating? Is there anything we >> can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that has >> a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one >> of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > > -- > J. Caleb Wherry > Scientific Software Engineer > > http://www.calebwherry.com > +1 (615) 708-5651 > [email protected] > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
