[cmake-developers] Profile Cmake scripts

Ben Boeckel ben.boeckel at kitware.com
Mon Jan 4 11:39:31 EST 2016


On Sun, Dec 27, 2015 at 22:04:14 +0100, Dimitar Yordanov wrote:
> I agree with you. Running valgrind directly on the cmake binary
> provides useful information: I can see which internal cmake functions
> are used the most and consume most of the time.
> 
> Nevertheless, I think it would be useful to have a higher level
> overview. E.g. to see if there are some issues with the scripts
> themselves that I use in my project ...

I had patches which did this, but it doesn't really help much. At least
I didn't think it did. The problems are mainly in CMake itself (regular
expressions, path parsing, etc.). I think the next big improvement would
be caching variable values which are parsed as numbers, on/off, and
paths as a more structured state so that if you have a path, path
operations don't have to keep searching for directory separators since
it is already in a std::vector<cmPathComponent> structure.

> > Usually you see mostly string handling related functions.
> 
> malloc and free are on the top of what I see for a random project used
> mostly by std::string. Maybe we can optimize something here too?

I did a lot of profiling of CMake two years ago. I fixed the low-hanging
fruit (rewriting the CMakeLists.txt parser/variable expander (CMP0053 if
you aren't using it), fixing other mini-parsers (escape routines, the
genex parser) to chunk rather than do char-by-char iteration, etc.). The
big remaining problem is passing char* as an argument where functions do
std::string(arg) right away. I fixed all of those which did explicit
std::string conversions (via assignment or otherwise), but those which
are conditional should get std::string overloads to avoid a
malloc/copy/free penalty. There is a *lot* of work here though. The
branch I had been working on (which is now woefully out-of-date) is 100
commits long.

--Ben


More information about the cmake-developers mailing list