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
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
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
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
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
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
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
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