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.cedil...@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.hoff...@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 -- 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