[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