[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 <andy.cedilnik at kitware.com>
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 <bill.hoffman at kitware.com>
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