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
