Re: [CMake] cmake script profiler

[Kyle Heath]

Volo,

Thanks for sharing your cmake-profile-stats tool... I found it very useful.
 With this tool and about ~10 minutes of tweaking, my configure phase runs
~4x faster!

@Bill: I hope similar profiling features will be included in a future
release!

Cheers,
Kyle

PS: I added a small extension to your script to print a cumulative summary
of time spent in each function.  This helped me find the hotspots quickly.
 I posted the modified script here:
https://code.google.com/p/cmake-profile-stats/issues/detail?id=1



On Wed, Apr 24, 2013 at 9:13 PM, Volo Zyko  wrote:

> We have executables and libraries and a lot of custom targets (the project
> is organized so that we export headers during the build - not the best idea
> in the world). However, I finished (more or less) the script for building
> time stats from the cmake's trace and we (with my colleague) found the
> slowest part. In our cmake scripts we have a bunch of sub-projects which
> produce libraries and also we have an utility function with which we define
> dependencies between those sub-projects. Then we define executables and
> build a list of libraries in a right order (from more dependent to less
> dependent) using sub-project's dependencies. This list is necessary for
> linking the executables. So, it appears that the slowest part is the
> function that builds the list of libraries. Basically there is nothing
> wrong with that cmake function, it just intensively works with strings. :(
>
> And here is where I put my script:
> https://code.google.com/p/cmake-profile-stats/ Comments are welcome.
>
> Also it looks like there are few bugs in the trace functionality of cmake;
> especially how callstack changes when cmake process foreach and if/else
> calls. I just didn't investigate them and I cannot provide more details.
> Sorry.
>
> --
>  Volo Zyko
>
> On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman 
> wrote:
>
>> On 4/24/2013 3:07 PM, Volo Zyko wrote:
>>
>>> Hi,
>>>
>>> We use Makefiles on Linux and MacOS. Windows is not our target platform.
>>> From what we see Linux is the fastest. We made few attempts of building
>>> our project on Windows in VS but it was very-very slow and definitely
>>> cmake generates too many project files for VS. For us it was 500+
>>> projects in a workspace which is too much for Visual Studio. :(
>>>
>> Chances are you have too many high level targets in your project.  What
>> types of targets do you have?  Are they all executables and libraries or
>> are you using custom targets to do something?   That might be a source of
>> your performance issues as well.
>>
>> -Bill
>>
>>
>> --
>> Bill Hoffman
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> bill.hoff...@kitware.com
>> http://www.kitware.com
>> 518 881-4905 (Direct)
>> 518 371-3971 x105
>> Fax (518) 371-4573
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/**
>> opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/**CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/**listinfo/cmake
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Alexander Neundorf]

On Wednesday 24 April 2013, Bill Hoffman wrote:
...
> > Without measuring anything, there is something else I thought about:
> > there are now a bunch of useful, quite complex macros coming with cmake,
> > which are used quite often: e.g. ExternalProject,
> > cmake_parse_arguments(),
> > find_package_handle_standard_args().
> > Every find-module or every macro which wants to use them, needs to
> > include() them. I haven't measured anything, but maybe reading and
> > parsing those relatively big files multiple times also consumes some
> > time.
> > This could be stripped off if cmake would include some modules by
> > default, so that as a user I could simply use them like built-in
> > commands, without the need to include() them again.
> 
> I am pretty sure we cache the read of an include, so multiple includes
> of the same file should not be that expensive.   

I had a quick look.
cmIncludeCommand calls cmMakefile::ReadListFile().
This then first tries to find the file, and then creates a variable  
cmListFile named cacheFile, and calls cacheFile.ParseFile().
This class is contained in cmListFileCache.h/cxx, which OTOH does not contain 
a class named cmListFileCache.
I don't see any caching going on.
There is a variable ModifiedTime set, but never used.
strace on a example file which include()s three times the same file in a row 
also shows that the file is read 3 times.

Seems it was indeed removed in 2006:
commit 4259971961aff5e6423eb72a4fad8acf7af79653
Author: Andy Cedilnik 
Date:   Tue Feb 7 08:49:42 2006 -0500

ENH: Since list file cache does not make much sense any more (because of 
proper list file parsing), and it actually adds unnecessary complications and 
make ctest scripting not work, take it out

And added by you 5 years before :-)

commit 5edd7673e1c7182c748584839ab1dec9712150b3
Author: Bill Hoffman 
Date:   Tue Aug 28 18:28:31 2001 -0400

ENH: add caching for the input CMakeList.txt files, 2X speed up


...
> > Inside cmake, arguments are handed over quite often as const char*, and
> > then converted again to std::string. Everytime this is done the end of
> > the string has to be searched, memory allocated and copied. Again, I
> > haven't measured (but I can remember vaguely from some profiling a few
> > years ago), maybe things would be faster if in more places const
> > std::string& would be used internally, this would get rid of quite some
> > strlen() calls.
> 
> I don' think this is true.  In fact, in the ninja generator it is
> spending the bulk of its time creating and destroying strings and it
> uses std:string much more frequently than the rest of cmake.   Again,
> this would require careful profiling before it could be determined if
> this would help or not.

Interesting. Yes, this would need profiling, as I said, I was just guessing.
Maybe it's those functions which return a std::string ?
In theory those should result in two strings, first the temporary one is 
created, and then this is copied into the target one.
Creating a std::string from a std::string& should be faster than creating one 
from a char*.
I just noticed that the Ninja generator files don't follow the CMake style of 
indenting curly braces in relatively big parts, more a K&R style.


Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Bill Hoffman]

On 4/24/2013 5:13 PM, Volo Zyko wrote:

We have executables and libraries and a lot of custom targets (the
project is organized so that we export headers during the build - not
the best idea in the world)


Can you consolidate them into larger custom targets that use custom 
commands instead?


add_custom_target(create_a_header COMMAND ...)  # lots of these are bad

add_custom_target(create_all_headers)
add_custom_command(...)   # lots of these that are part of the one 
target is good

add_custom_command(...)

Should even make your makefiles faster.

-Bill

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Jean-Christophe Fillion-Robin]

Hi,

If it turns out to be usefull for you. We could also consider creating a
dedicated github project to avoid code duplication. That way you would be
able to either add it as a git submodule to your project or checkout this
new small project at configure time [1]

Hth
Jc

[1]
http://cmake.3232098.n2.nabble.com/is-it-possible-to-download-CMake-modules-at-configure-time-td7583968.html


On Wed, Apr 24, 2013 at 5:32 PM, Volo Zyko  wrote:

> Hi Jean-Christophe,
>
> Thanks for the suggestion. We'll definitely consider it.
>
> --
>  Volo Zyko
>
> On Thu, Apr 25, 2013 at 12:23 AM, Jean-Christophe Fillion-Robin <
> jchris.filli...@kitware.com> wrote:
>
>> Hi Volo,
>>
>> If you are doing some topological sorting to build your
>> library/executable in the right order. Instead of using CMake based
>> solution, you could may be rely on a C++ approach ? This is what we are
>> doing in CTK. We are using a small prog named ctkDependencyGraph that we
>> build at configure time.
>> See [1-4]
>>
>> [1]
>> http://www.commontk.org/index.php/Documentation/BuildSystem_Description
>> [2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717
>> [3]
>> https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake
>> [4]
>> https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150
>>
>>
>>
>> On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko  wrote:
>>
>>> We have executables and libraries and a lot of custom targets (the
>>> project is organized so that we export headers during the build - not the
>>> best idea in the world). However, I finished (more or less) the script for
>>> building time stats from the cmake's trace and we (with my colleague) found
>>> the slowest part. In our cmake scripts we have a bunch of sub-projects
>>> which produce libraries and also we have an utility function with which we
>>> define dependencies between those sub-projects. Then we define executables
>>> and build a list of libraries in a right order (from more dependent to less
>>> dependent) using sub-project's dependencies. This list is necessary for
>>> linking the executables. So, it appears that the slowest part is the
>>> function that builds the list of libraries. Basically there is nothing
>>> wrong with that cmake function, it just intensively works with strings. :(
>>>
>>> And here is where I put my script:
>>> https://code.google.com/p/cmake-profile-stats/ Comments are welcome.
>>>
>>> Also it looks like there are few bugs in the trace functionality of
>>> cmake; especially how callstack changes when cmake process foreach and
>>> if/else calls. I just didn't investigate them and I cannot provide more
>>> details. Sorry.
>>>
>>> --
>>>  Volo Zyko
>>>
>>> On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman >> > wrote:
>>>
 On 4/24/2013 3:07 PM, Volo Zyko wrote:

> Hi,
>
> We use Makefiles on Linux and MacOS. Windows is not our target
> platform.
> From what we see Linux is the fastest. We made few attempts of building
> our project on Windows in VS but it was very-very slow and definitely
> cmake generates too many project files for VS. For us it was 500+
> projects in a workspace which is too much for Visual Studio. :(
>
 Chances are you have too many high level targets in your project.  What
 types of targets do you have?  Are they all executables and libraries or
 are you using custom targets to do something?   That might be a source of
 your performance issues as well.

 -Bill


 --
 Bill Hoffman
 Kitware, Inc.
 28 Corporate Drive
 Clifton Park, NY 12065
 bill.hoff...@kitware.com
 http://www.kitware.com
 518 881-4905 (Direct)
 518 371-3971 x105
 Fax (518) 371-4573

 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmake

>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> +1 919 869 8849
>>
>
>
>


-- 
+1 919 869 8849
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http:

Re: [CMake] cmake script profiler

[Volo Zyko]

Hi Jean-Christophe,

Thanks for the suggestion. We'll definitely consider it.

-- 
 Volo Zyko

On Thu, Apr 25, 2013 at 12:23 AM, Jean-Christophe Fillion-Robin <
jchris.filli...@kitware.com> wrote:

> Hi Volo,
>
> If you are doing some topological sorting to build your library/executable
> in the right order. Instead of using CMake based solution, you could may be
> rely on a C++ approach ? This is what we are doing in CTK. We are using a
> small prog named ctkDependencyGraph that we build at configure time.
> See [1-4]
>
> [1]
> http://www.commontk.org/index.php/Documentation/BuildSystem_Description
> [2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717
> [3]
> https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake
> [4]
> https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150
>
>
>
> On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko  wrote:
>
>> We have executables and libraries and a lot of custom targets (the
>> project is organized so that we export headers during the build - not the
>> best idea in the world). However, I finished (more or less) the script for
>> building time stats from the cmake's trace and we (with my colleague) found
>> the slowest part. In our cmake scripts we have a bunch of sub-projects
>> which produce libraries and also we have an utility function with which we
>> define dependencies between those sub-projects. Then we define executables
>> and build a list of libraries in a right order (from more dependent to less
>> dependent) using sub-project's dependencies. This list is necessary for
>> linking the executables. So, it appears that the slowest part is the
>> function that builds the list of libraries. Basically there is nothing
>> wrong with that cmake function, it just intensively works with strings. :(
>>
>> And here is where I put my script:
>> https://code.google.com/p/cmake-profile-stats/ Comments are welcome.
>>
>> Also it looks like there are few bugs in the trace functionality of
>> cmake; especially how callstack changes when cmake process foreach and
>> if/else calls. I just didn't investigate them and I cannot provide more
>> details. Sorry.
>>
>> --
>>  Volo Zyko
>>
>> On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman 
>> wrote:
>>
>>> On 4/24/2013 3:07 PM, Volo Zyko wrote:
>>>
 Hi,

 We use Makefiles on Linux and MacOS. Windows is not our target platform.
 From what we see Linux is the fastest. We made few attempts of building
 our project on Windows in VS but it was very-very slow and definitely
 cmake generates too many project files for VS. For us it was 500+
 projects in a workspace which is too much for Visual Studio. :(

>>> Chances are you have too many high level targets in your project.  What
>>> types of targets do you have?  Are they all executables and libraries or
>>> are you using custom targets to do something?   That might be a source of
>>> your performance issues as well.
>>>
>>> -Bill
>>>
>>>
>>> --
>>> Bill Hoffman
>>> Kitware, Inc.
>>> 28 Corporate Drive
>>> Clifton Park, NY 12065
>>> bill.hoff...@kitware.com
>>> http://www.kitware.com
>>> 518 881-4905 (Direct)
>>> 518 371-3971 x105
>>> Fax (518) 371-4573
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/**
>>> opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/**CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/**listinfo/cmake
>>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
>
> --
> +1 919 869 8849
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Jean-Christophe Fillion-Robin]

Hi Volo,

If you are doing some topological sorting to build your library/executable
in the right order. Instead of using CMake based solution, you could may be
rely on a C++ approach ? This is what we are doing in CTK. We are using a
small prog named ctkDependencyGraph that we build at configure time.
See [1-4]

[1] http://www.commontk.org/index.php/Documentation/BuildSystem_Description
[2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717
[3]
https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake
[4]
https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150



On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko  wrote:

> We have executables and libraries and a lot of custom targets (the project
> is organized so that we export headers during the build - not the best idea
> in the world). However, I finished (more or less) the script for building
> time stats from the cmake's trace and we (with my colleague) found the
> slowest part. In our cmake scripts we have a bunch of sub-projects which
> produce libraries and also we have an utility function with which we define
> dependencies between those sub-projects. Then we define executables and
> build a list of libraries in a right order (from more dependent to less
> dependent) using sub-project's dependencies. This list is necessary for
> linking the executables. So, it appears that the slowest part is the
> function that builds the list of libraries. Basically there is nothing
> wrong with that cmake function, it just intensively works with strings. :(
>
> And here is where I put my script:
> https://code.google.com/p/cmake-profile-stats/ Comments are welcome.
>
> Also it looks like there are few bugs in the trace functionality of cmake;
> especially how callstack changes when cmake process foreach and if/else
> calls. I just didn't investigate them and I cannot provide more details.
> Sorry.
>
> --
>  Volo Zyko
>
> On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman 
> wrote:
>
>> On 4/24/2013 3:07 PM, Volo Zyko wrote:
>>
>>> Hi,
>>>
>>> We use Makefiles on Linux and MacOS. Windows is not our target platform.
>>> From what we see Linux is the fastest. We made few attempts of building
>>> our project on Windows in VS but it was very-very slow and definitely
>>> cmake generates too many project files for VS. For us it was 500+
>>> projects in a workspace which is too much for Visual Studio. :(
>>>
>> Chances are you have too many high level targets in your project.  What
>> types of targets do you have?  Are they all executables and libraries or
>> are you using custom targets to do something?   That might be a source of
>> your performance issues as well.
>>
>> -Bill
>>
>>
>> --
>> Bill Hoffman
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> bill.hoff...@kitware.com
>> http://www.kitware.com
>> 518 881-4905 (Direct)
>> 518 371-3971 x105
>> Fax (518) 371-4573
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/**
>> opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/**CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/**listinfo/cmake
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
+1 919 869 8849
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Volo Zyko]

We have executables and libraries and a lot of custom targets (the project
is organized so that we export headers during the build - not the best idea
in the world). However, I finished (more or less) the script for building
time stats from the cmake's trace and we (with my colleague) found the
slowest part. In our cmake scripts we have a bunch of sub-projects which
produce libraries and also we have an utility function with which we define
dependencies between those sub-projects. Then we define executables and
build a list of libraries in a right order (from more dependent to less
dependent) using sub-project's dependencies. This list is necessary for
linking the executables. So, it appears that the slowest part is the
function that builds the list of libraries. Basically there is nothing
wrong with that cmake function, it just intensively works with strings. :(

And here is where I put my script:
https://code.google.com/p/cmake-profile-stats/ Comments are welcome.

Also it looks like there are few bugs in the trace functionality of cmake;
especially how callstack changes when cmake process foreach and if/else
calls. I just didn't investigate them and I cannot provide more details.
Sorry.

-- 
 Volo Zyko

On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman wrote:

> On 4/24/2013 3:07 PM, Volo Zyko wrote:
>
>> Hi,
>>
>> We use Makefiles on Linux and MacOS. Windows is not our target platform.
>> From what we see Linux is the fastest. We made few attempts of building
>> our project on Windows in VS but it was very-very slow and definitely
>> cmake generates too many project files for VS. For us it was 500+
>> projects in a workspace which is too much for Visual Studio. :(
>>
> Chances are you have too many high level targets in your project.  What
> types of targets do you have?  Are they all executables and libraries or
> are you using custom targets to do something?   That might be a source of
> your performance issues as well.
>
> -Bill
>
>
> --
> Bill Hoffman
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> bill.hoff...@kitware.com
> http://www.kitware.com
> 518 881-4905 (Direct)
> 518 371-3971 x105
> Fax (518) 371-4573
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Bill Hoffman]

On 4/24/2013 3:18 PM, Alexander Neundorf wrote:


When looking at this I wouldn't know immediately where to start when trying to
make it faster, probably _vtk_module_config_recurse().
set() is probably there because it is called really often.
I would assume that if() is called significantly less often, so maybe this
could use some optimization.
Can you produce those numbers also for processed files, instead of commands ?



Well for this build _vtk_module_config_recurse is more like main in a 
C++ function, everything gets processed by it.   I think Volo's idea 
might be better for getting information like that.


Without measuring anything, there is something else I thought about: there are
now a bunch of useful, quite complex macros coming with cmake, which are used
quite often: e.g. ExternalProject, cmake_parse_arguments(),
find_package_handle_standard_args().
Every find-module or every macro which wants to use them, needs to include()
them. I haven't measured anything, but maybe reading and parsing those
relatively big files multiple times also consumes some time.
This could be stripped off if cmake would include some modules by default, so
that as a user I could simply use them like built-in commands, without the
need to include() them again.


I am pretty sure we cache the read of an include, so multiple includes 
of the same file should not be that expensive.   We would have to 
profile some projects and see if it was a real issue before doing 
something like that.  Right now from what I have seen I would not expect 
that to make much of a difference.





Also, thinking of adding some stats to number of times a variable is set
and how many variables are used.


Hopefully this won't make set() take more time ;-)
No, this would all be an option --profile.   The variable set one might 
not make sense to users.  I did find that MATCH_N was being set far too 
many times for no reason and was able to optimize that part of the code.




Inside cmake, arguments are handed over quite often as const char*, and then
converted again to std::string. Everytime this is done the end of the string
has to be searched, memory allocated and copied. Again, I haven't measured
(but I can remember vaguely from some profiling a few years ago), maybe things
would be faster if in more places const std::string& would be used internally,
this would get rid of quite some strlen() calls.


I don' think this is true.  In fact, in the ninja generator it is 
spending the bulk of its time creating and destroying strings and it 
uses std:string much more frequently than the rest of cmake.   Again, 
this would require careful profiling before it could be determined if 
this would help or not.


-Bill
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Alexander Neundorf]

On Tuesday 23 April 2013, Bill Hoffman wrote:
> On 4/23/2013 3:50 PM, Volo Zyko wrote:
> > Hi all,
> > 
> > We have a rather big project and use cmake for building it. At some
> > point our cmake scripts became very slow (around 4 minutes for single
> > cmake run). We are thinking now how to speed up it. Searching the web
> > and this list didn't give any results. It looks like there is no such
> > thing as profiler for cmake scripts. Am I right?
> > 
> > What about adding such capability to cmake? It looks like cmake's trace
> > provides enough info for time profiling, the only thing that it lacks is
> > a time stamp. Below is a small patch that adds time stamp and nesting
> > level (to simplify building a stack trace) to each trace line. Would it
> > be possible to integrate this change to the main line or are there
> > better options for time profiling of cmake?
> 
> That's funny.  I was just playing around with adding a profile option.
> My approach was to sum up all the time spent in each function.  It does
> not have a call stack but, should give you an idea of where it is
> spending the bulk of the time.   I suppose you could post process the
> output of a trace with your change, but that would be more work.
> 
> An example of my output on the ParaView project:
> 
> 4.881 export
> 4.97701 vtk_wrap_python
> 5.15999 vtk_module_export
> 5.45701 VTK_WRAP_ClientServer
> 5.817 QT4_GET_MOC_FLAGS
> 6.159 vtk_module_impl
> 6.38601 pv_pre_wrap_vtk_mod_cs
> 7.08994 if
> 7.23499 vtk_add_python_wrapping
> 7.46001 QT4_WRAP_CPP
> 7.71494 configure_file
> 8.59399 vtk_module_config
> 8.904 pv_process_plugins
> 8.987 vtk_add_cs_wrapping
> 9.64503 set
> 11.654 try_compile
> 12.748 vtk_module_third_party
> 17.007 vtk_module_library
> 37.773 _vtk_module_config_recurse
> 112.788 include
> 158.092 add_subdirectory

When looking at this I wouldn't know immediately where to start when trying to 
make it faster, probably _vtk_module_config_recurse().
set() is probably there because it is called really often.
I would assume that if() is called significantly less often, so maybe this 
could use some optimization.
Can you produce those numbers also for processed files, instead of commands ?


Without measuring anything, there is something else I thought about: there are 
now a bunch of useful, quite complex macros coming with cmake, which are used 
quite often: e.g. ExternalProject, cmake_parse_arguments(), 
find_package_handle_standard_args().
Every find-module or every macro which wants to use them, needs to include() 
them. I haven't measured anything, but maybe reading and parsing those 
relatively big files multiple times also consumes some time.
This could be stripped off if cmake would include some modules by default, so 
that as a user I could simply use them like built-in commands, without the 
need to include() them again.

> Also, thinking of adding some stats to number of times a variable is set
> and how many variables are used.

Hopefully this won't make set() take more time ;-)

Inside cmake, arguments are handed over quite often as const char*, and then 
converted again to std::string. Everytime this is done the end of the string 
has to be searched, memory allocated and copied. Again, I haven't measured 
(but I can remember vaguely from some profiling a few years ago), maybe things 
would be faster if in more places const std::string& would be used internally, 
this would get rid of quite some strlen() calls.

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Bill Hoffman]

On 4/24/2013 3:07 PM, Volo Zyko wrote:

Hi,

We use Makefiles on Linux and MacOS. Windows is not our target platform.
From what we see Linux is the fastest. We made few attempts of building
our project on Windows in VS but it was very-very slow and definitely
cmake generates too many project files for VS. For us it was 500+
projects in a workspace which is too much for Visual Studio. :(
Chances are you have too many high level targets in your project.  What 
types of targets do you have?  Are they all executables and libraries or 
are you using custom targets to do something?   That might be a source 
of your performance issues as well.


-Bill


--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Volo Zyko]

Hi,

We use Makefiles on Linux and MacOS. Windows is not our target platform.
>From what we see Linux is the fastest. We made few attempts of building our
project on Windows in VS but it was very-very slow and definitely cmake
generates too many project files for VS. For us it was 500+ projects in a
workspace which is too much for Visual Studio. :(

-- 
 Volo Zyko

On Wed, Apr 24, 2013 at 12:37 PM, Gregoire Aujay  wrote:

>  Hello,
>
> ** **
>
> Are you using cmake with a Makefiles generator on Windows ?
>
> ** **
>
> From my experiments here are my observations:
>
> **-  **Makefiles on Windows: slow
>
> **-  **Visual ide generator : fast
>
> **-  **Makefiles on linux: fast
>
> ** **
>
> I found that when there are many targets in a project, cmake has to write
> many small files on the HD which seems to be very slow on windows.
>
> ** **
>
> Regards,
>
> Gregoire
>
> ** **
>
> ** **
>
> *From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
> Behalf Of *Volo Zyko
> *Sent:* mardi 23 avril 2013 21:51
> *To:* cmake@cmake.org
> *Subject:* [CMake] cmake script profiler
>
> ** **
>
> Hi all,
>
> ** **
>
> We have a rather big project and use cmake for building it. At some point
> our cmake scripts became very slow (around 4 minutes for single cmake run).
> We are thinking now how to speed up it. Searching the web and this list
> didn't give any results. It looks like there is no such thing as profiler
> for cmake scripts. Am I right?
>
> ** **
>
> What about adding such capability to cmake? It looks like cmake's trace
> provides enough info for time profiling, the only thing that it lacks is a
> time stamp. Below is a small patch that adds time stamp and nesting level
> (to simplify building a stack trace) to each trace line. Would it be
> possible to integrate this change to the main line or are there better
> options for time profiling of cmake?
>
> ** **
>
> diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
>
> index 25ccbc7..0e6725c 100644
>
> --- a/Source/cmMakefile.cxx
>
> +++ b/Source/cmMakefile.cxx
>
> @@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace&
> backtrace) const
>
>  void cmMakefile::PrintCommandTrace(const cmListFileFunction& lff)
>
>  {
>
>cmOStringStream msg;
>
> +  msg << "(" << std::fixed << cmSystemTools::GetTime();
>
> +  msg << ") (" << this->CallStack.size() << ") ";
>
>msg << lff.FilePath << "(" << lff.Line << "):  ";
>
>msg << lff.Name << "(";
>
>for(std::vector::const_iterator i =
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Bill Hoffman]

On 4/24/2013 5:37 AM, Gregoire Aujay wrote:

Hello,

Are you using cmake with a Makefiles generator on Windows ?

 From my experiments here are my observations:

-Makefiles on Windows: slow

-Visual ide generator : fast

-Makefiles on linux: fast

I found that when there are many targets in a project, cmake has to
write many small files on the HD which seems to be very slow on windows.

Regards,

Gregoire



So, I just did some timing on ParaView which is a big project (includes 
VTK).   This is all on windows.  It seems that ninja is the slow one. 
The makefile and VS 10 generator were about the same.  This is a second 
configure, so it does not include the initial try-compile stuff which 
can be slow on windows.


vs 10   real2m41.935s

ninjareal3m33.807s

unix makefiles  real2m43.696s


-Bill

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Gregoire Aujay]

Hello,

Are you using cmake with a Makefiles generator on Windows ?

>From my experiments here are my observations:

-  Makefiles on Windows: slow

-  Visual ide generator : fast

-  Makefiles on linux: fast

I found that when there are many targets in a project, cmake has to write many 
small files on the HD which seems to be very slow on windows.

Regards,
Gregoire


From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of 
Volo Zyko
Sent: mardi 23 avril 2013 21:51
To: cmake@cmake.org
Subject: [CMake] cmake script profiler

Hi all,

We have a rather big project and use cmake for building it. At some point our 
cmake scripts became very slow (around 4 minutes for single cmake run). We are 
thinking now how to speed up it. Searching the web and this list didn't give 
any results. It looks like there is no such thing as profiler for cmake 
scripts. Am I right?

What about adding such capability to cmake? It looks like cmake's trace 
provides enough info for time profiling, the only thing that it lacks is a time 
stamp. Below is a small patch that adds time stamp and nesting level (to 
simplify building a stack trace) to each trace line. Would it be possible to 
integrate this change to the main line or are there better options for time 
profiling of cmake?

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..0e6725c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace& 
backtrace) const
 void cmMakefile::PrintCommandTrace(const cmListFileFunction& lff)
 {
   cmOStringStream msg;
+  msg << "(" << std::fixed << cmSystemTools::GetTime();
+  msg << ") (" << this->CallStack.size() << ") ";
   msg << lff.FilePath << "(" << lff.Line << "):  ";
   msg << lff.Name << "(";
   for(std::vector::const_iterator i =
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Volo Zyko]

On Wed, Apr 24, 2013 at 12:07 AM, Bill Hoffman 
wrote:
> That's funny.  I was just playing around with adding a profile option. My
approach was to sum up all the time spent in each function.  It does not
have a call stack but, should give you an idea of where it is spending the
bulk of the time.   I suppose you could post process the output of a trace
with your change, but that would be more work.

I have a Python script that processes the cmake trace and creates stack
traces. I'm polishing it right now and I'm planning  to make it public on
github or other similar service. No matter whether my patch for cmake will
be accepted or not the script might be useful for other people.

--
 Volo Zyko
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Jean-Christophe Fillion-Robin]

Hi Bill,

Would it be possible to share the topic implementing your profiling code ?

By default, summing the time spent in each functions makes sens.

That said, it would also be nice to have the option of having detailed
trace info, coupled with convenient code like "message("START_PROFILING")
and message("STOP_PROFILING"), it would allow to get stats on a subset of
the configure step. Having stats per directory would also be nice.

Leveraging GUI like KCacheGrind [1] to visualize the profiling files could
also be an option.

Thanks
Jc

[1] http://kcachegrind.sourceforge.net/html/Shot3Large.html


On Tue, Apr 23, 2013 at 4:24 PM, Bill Hoffman wrote:

> On 4/23/2013 3:50 PM, Volo Zyko wrote:
>
>> Hi all,
>>
>> We have a rather big project and use cmake for building it. At some
>> point our cmake scripts became very slow (around 4 minutes for single
>> cmake run). We are thinking now how to speed up it. Searching the web
>> and this list didn't give any results. It looks like there is no such
>> thing as profiler for cmake scripts. Am I right?
>>
>> What about adding such capability to cmake? It looks like cmake's trace
>> provides enough info for time profiling, the only thing that it lacks is
>> a time stamp. Below is a small patch that adds time stamp and nesting
>> level (to simplify building a stack trace) to each trace line. Would it
>> be possible to integrate this change to the main line or are there
>> better options for time profiling of cmake?
>>
>
> That's funny.  I was just playing around with adding a profile option. My
> approach was to sum up all the time spent in each function.  It does not
> have a call stack but, should give you an idea of where it is spending the
> bulk of the time.   I suppose you could post process the output of a trace
> with your change, but that would be more work.
>
> An example of my output on the ParaView project:
>
> 4.881 export
> 4.97701 vtk_wrap_python
> 5.15999 vtk_module_export
> 5.45701 VTK_WRAP_ClientServer
> 5.817 QT4_GET_MOC_FLAGS
> 6.159 vtk_module_impl
> 6.38601 pv_pre_wrap_vtk_mod_cs
> 7.08994 if
> 7.23499 vtk_add_python_wrapping
> 7.46001 QT4_WRAP_CPP
> 7.71494 configure_file
> 8.59399 vtk_module_config
> 8.904 pv_process_plugins
> 8.987 vtk_add_cs_wrapping
> 9.64503 set
> 11.654 try_compile
> 12.748 vtk_module_third_party
> 17.007 vtk_module_library
> 37.773 _vtk_module_config_recurse
> 112.788 include
> 158.092 add_subdirectory
>
> Also, thinking of adding some stats to number of times a variable is set
> and how many variables are used.
>
> -Bill
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake
>



-- 
+1 919 869 8849
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake script profiler

[Bill Hoffman]

On 4/23/2013 3:50 PM, Volo Zyko wrote:

Hi all,

We have a rather big project and use cmake for building it. At some
point our cmake scripts became very slow (around 4 minutes for single
cmake run). We are thinking now how to speed up it. Searching the web
and this list didn't give any results. It looks like there is no such
thing as profiler for cmake scripts. Am I right?

What about adding such capability to cmake? It looks like cmake's trace
provides enough info for time profiling, the only thing that it lacks is
a time stamp. Below is a small patch that adds time stamp and nesting
level (to simplify building a stack trace) to each trace line. Would it
be possible to integrate this change to the main line or are there
better options for time profiling of cmake?


That's funny.  I was just playing around with adding a profile option. 
My approach was to sum up all the time spent in each function.  It does 
not have a call stack but, should give you an idea of where it is 
spending the bulk of the time.   I suppose you could post process the 
output of a trace with your change, but that would be more work.


An example of my output on the ParaView project:

4.881 export
4.97701 vtk_wrap_python
5.15999 vtk_module_export
5.45701 VTK_WRAP_ClientServer
5.817 QT4_GET_MOC_FLAGS
6.159 vtk_module_impl
6.38601 pv_pre_wrap_vtk_mod_cs
7.08994 if
7.23499 vtk_add_python_wrapping
7.46001 QT4_WRAP_CPP
7.71494 configure_file
8.59399 vtk_module_config
8.904 pv_process_plugins
8.987 vtk_add_cs_wrapping
9.64503 set
11.654 try_compile
12.748 vtk_module_third_party
17.007 vtk_module_library
37.773 _vtk_module_config_recurse
112.788 include
158.092 add_subdirectory

Also, thinking of adding some stats to number of times a variable is set 
and how many variables are used.


-Bill


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake