Re: [CMake] CMake Project Generation Speedup

2019-03-21 Thread Robert Maynard via CMake
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

Re: [CMake] CMake Project Generation Speedup

2019-03-21 Thread Cristian Adam
Hi, CMake has for Visual Studio is a multi configuration generator. (Debug, Release, RelMinSize, RelWithDbgInformation). If you specify only one configuration you should cut the generation time to 1/4th. See https://cmake.org/cmake/help/latest/variable/CMAKE_CONFIGURATION_TYPES.html#variable:CMA

Re: [CMake] CMake Project Generation Speedup

2019-03-21 Thread Gregor Jasny via CMake
Hello, On 17.11.16 17:15, Damian wrote: 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

Re: [CMake] CMake Project Generation Speedup

2019-03-20 Thread Kuba Ober
The best advice I had for myself: profile the code and tweak it. The last I looked, and that was a while ago, the generators could use a threaded write queue so that the file output would overlap with file generation. Those probably could be memory mapped files, too, to further minimize the over

Re: [CMake] CMake Project Generation Speedup

2019-03-20 Thread Kyle Edwards via CMake
On Wed, 2019-03-20 at 16:57 -0400, J. Caleb Wherry wrote: > I was also surprised when "cmake --trace" gave 0 information related > to the generate step. I assume this is expected behavior? The purpose of --trace is to debug CMake scripts. No scripts get run during the generate step, so yes, this is

Re: [CMake] CMake Project Generation Speedup

2019-03-20 Thread J. Caleb Wherry
I was also surprised when "cmake --trace" gave 0 information related to the generate step. I assume this is expected behavior? Oh and: CMake: 3.13.4 Visual Studio 2017 15.9.9 Win7 -Caleb On Wed, Mar 20, 2019 at 4:53 PM J. Caleb Wherry wrote: > Did anything ever come of this? > > I am in a sim

Re: [CMake] CMake Project Generation Speedup

2019-03-20 Thread J. Caleb Wherry
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

[CMake] CMake Project Generation Speedup

2016-11-17 Thread Damian
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 an