Re: [CMake] cmake script profiler
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 KR 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
Re: [CMake] cmake script profiler
Volo, Thanks for sharing your cmake-profile-stats tool... I found it very useful. With this tool and about ~10 minutes of tweaking, my configure phase runs ~4x faster! @Bill: I hope similar profiling features will be included in a future release! Cheers, Kyle PS: I added a small extension to your script to print a cumulative summary of time spent in each function. This helped me find the hotspots quickly. I posted the modified script here: https://code.google.com/p/cmake-profile-stats/issues/detail?id=1 On Wed, Apr 24, 2013 at 9:13 PM, Volo Zyko volo.z...@gmail.com wrote: We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world). However, I finished (more or less) the script for building time stats from the cmake's trace and we (with my colleague) found the slowest part. In our cmake scripts we have a bunch of sub-projects which produce libraries and also we have an utility function with which we define dependencies between those sub-projects. Then we define executables and build a list of libraries in a right order (from more dependent to less dependent) using sub-project's dependencies. This list is necessary for linking the executables. So, it appears that the slowest part is the function that builds the list of libraries. Basically there is nothing wrong with that cmake function, it just intensively works with strings. :( And here is where I put my script: https://code.google.com/p/cmake-profile-stats/ Comments are welcome. Also it looks like there are few bugs in the trace functionality of cmake; especially how callstack changes when cmake process foreach and if/else calls. I just didn't investigate them and I cannot provide more details. Sorry. -- Volo Zyko On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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 -- 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
Re: [CMake] cmake script profiler
Hello,
Are you using cmake with a Makefiles generator on Windows ?
From my experiments here are my observations:
- Makefiles on Windows: slow
- Visual ide generator : fast
- Makefiles on linux: fast
I found that when there are many targets in a project, cmake has to write many
small files on the HD which seems to be very slow on windows.
Regards,
Gregoire
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Volo Zyko
Sent: mardi 23 avril 2013 21:51
To: cmake@cmake.org
Subject: [CMake] cmake script profiler
Hi all,
We have a rather big project and use cmake for building it. At some point our
cmake scripts became very slow (around 4 minutes for single cmake run). We are
thinking now how to speed up it. Searching the web and this list didn't give
any results. It looks like there is no such thing as profiler for cmake
scripts. Am I right?
What about adding such capability to cmake? It looks like cmake's trace
provides enough info for time profiling, the only thing that it lacks is a time
stamp. Below is a small patch that adds time stamp and nesting level (to
simplify building a stack trace) to each trace line. Would it be possible to
integrate this change to the main line or are there better options for time
profiling of cmake?
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..0e6725c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace
backtrace) const
void cmMakefile::PrintCommandTrace(const cmListFileFunction lff)
{
cmOStringStream msg;
+ msg ( std::fixed cmSystemTools::GetTime();
+ msg ) ( this-CallStack.size() ) ;
msg lff.FilePath ( lff.Line ): ;
msg lff.Name (;
for(std::vectorcmListFileArgument::const_iterator i =
--
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
Re: [CMake] cmake script profiler
On 4/24/2013 5:37 AM, Gregoire Aujay wrote: Hello, Are you using cmake with a Makefiles generator on Windows ? From my experiments here are my observations: -Makefiles on Windows: slow -Visual ide generator : fast -Makefiles on linux: fast I found that when there are many targets in a project, cmake has to write many small files on the HD which seems to be very slow on windows. Regards, Gregoire So, I just did some timing on ParaView which is a big project (includes VTK). This is all on windows. It seems that ninja is the slow one. The makefile and VS 10 generator were about the same. This is a second configure, so it does not include the initial try-compile stuff which can be slow on windows. vs 10 real2m41.935s ninjareal3m33.807s unix makefiles real2m43.696s -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
Re: [CMake] cmake script profiler
Hi,
We use Makefiles on Linux and MacOS. Windows is not our target platform.
From what we see Linux is the fastest. We made few attempts of building our
project on Windows in VS but it was very-very slow and definitely cmake
generates too many project files for VS. For us it was 500+ projects in a
workspace which is too much for Visual Studio. :(
--
Volo Zyko
On Wed, Apr 24, 2013 at 12:37 PM, Gregoire Aujay gau...@movea.com wrote:
Hello,
** **
Are you using cmake with a Makefiles generator on Windows ?
** **
From my experiments here are my observations:
**- **Makefiles on Windows: slow
**- **Visual ide generator : fast
**- **Makefiles on linux: fast
** **
I found that when there are many targets in a project, cmake has to write
many small files on the HD which seems to be very slow on windows.
** **
Regards,
Gregoire
** **
** **
*From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
Behalf Of *Volo Zyko
*Sent:* mardi 23 avril 2013 21:51
*To:* cmake@cmake.org
*Subject:* [CMake] cmake script profiler
** **
Hi all,
** **
We have a rather big project and use cmake for building it. At some point
our cmake scripts became very slow (around 4 minutes for single cmake run).
We are thinking now how to speed up it. Searching the web and this list
didn't give any results. It looks like there is no such thing as profiler
for cmake scripts. Am I right?
** **
What about adding such capability to cmake? It looks like cmake's trace
provides enough info for time profiling, the only thing that it lacks is a
time stamp. Below is a small patch that adds time stamp and nesting level
(to simplify building a stack trace) to each trace line. Would it be
possible to integrate this change to the main line or are there better
options for time profiling of cmake?
** **
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..0e6725c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace
backtrace) const
void cmMakefile::PrintCommandTrace(const cmListFileFunction lff)
{
cmOStringStream msg;
+ msg ( std::fixed cmSystemTools::GetTime();
+ msg ) ( this-CallStack.size() ) ;
msg lff.FilePath ( lff.Line ): ;
msg lff.Name (;
for(std::vectorcmListFileArgument::const_iterator i =
--
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
Re: [CMake] cmake script profiler
On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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
Re: [CMake] cmake script profiler
On Tuesday 23 April 2013, Bill Hoffman wrote: On 4/23/2013 3:50 PM, Volo Zyko wrote: Hi all, We have a rather big project and use cmake for building it. At some point our cmake scripts became very slow (around 4 minutes for single cmake run). We are thinking now how to speed up it. Searching the web and this list didn't give any results. It looks like there is no such thing as profiler for cmake scripts. Am I right? What about adding such capability to cmake? It looks like cmake's trace provides enough info for time profiling, the only thing that it lacks is a time stamp. Below is a small patch that adds time stamp and nesting level (to simplify building a stack trace) to each trace line. Would it be possible to integrate this change to the main line or are there better options for time profiling of cmake? That's funny. I was just playing around with adding a profile option. My approach was to sum up all the time spent in each function. It does not have a call stack but, should give you an idea of where it is spending the bulk of the time. I suppose you could post process the output of a trace with your change, but that would be more work. An example of my output on the ParaView project: 4.881 export 4.97701 vtk_wrap_python 5.15999 vtk_module_export 5.45701 VTK_WRAP_ClientServer 5.817 QT4_GET_MOC_FLAGS 6.159 vtk_module_impl 6.38601 pv_pre_wrap_vtk_mod_cs 7.08994 if 7.23499 vtk_add_python_wrapping 7.46001 QT4_WRAP_CPP 7.71494 configure_file 8.59399 vtk_module_config 8.904 pv_process_plugins 8.987 vtk_add_cs_wrapping 9.64503 set 11.654 try_compile 12.748 vtk_module_third_party 17.007 vtk_module_library 37.773 _vtk_module_config_recurse 112.788 include 158.092 add_subdirectory 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 ? 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. 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 ;-) 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. 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
Re: [CMake] cmake script profiler
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
Re: [CMake] cmake script profiler
We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world). However, I finished (more or less) the script for building time stats from the cmake's trace and we (with my colleague) found the slowest part. In our cmake scripts we have a bunch of sub-projects which produce libraries and also we have an utility function with which we define dependencies between those sub-projects. Then we define executables and build a list of libraries in a right order (from more dependent to less dependent) using sub-project's dependencies. This list is necessary for linking the executables. So, it appears that the slowest part is the function that builds the list of libraries. Basically there is nothing wrong with that cmake function, it just intensively works with strings. :( And here is where I put my script: https://code.google.com/p/cmake-profile-stats/ Comments are welcome. Also it looks like there are few bugs in the trace functionality of cmake; especially how callstack changes when cmake process foreach and if/else calls. I just didn't investigate them and I cannot provide more details. Sorry. -- Volo Zyko On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] cmake script profiler
Hi Volo, If you are doing some topological sorting to build your library/executable in the right order. Instead of using CMake based solution, you could may be rely on a C++ approach ? This is what we are doing in CTK. We are using a small prog named ctkDependencyGraph that we build at configure time. See [1-4] [1] http://www.commontk.org/index.php/Documentation/BuildSystem_Description [2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717 [3] https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake [4] https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150 On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko volo.z...@gmail.com wrote: We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world). However, I finished (more or less) the script for building time stats from the cmake's trace and we (with my colleague) found the slowest part. In our cmake scripts we have a bunch of sub-projects which produce libraries and also we have an utility function with which we define dependencies between those sub-projects. Then we define executables and build a list of libraries in a right order (from more dependent to less dependent) using sub-project's dependencies. This list is necessary for linking the executables. So, it appears that the slowest part is the function that builds the list of libraries. Basically there is nothing wrong with that cmake function, it just intensively works with strings. :( And here is where I put my script: https://code.google.com/p/cmake-profile-stats/ Comments are welcome. Also it looks like there are few bugs in the trace functionality of cmake; especially how callstack changes when cmake process foreach and if/else calls. I just didn't investigate them and I cannot provide more details. Sorry. -- Volo Zyko On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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 -- +1 919 869 8849 -- 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
Re: [CMake] cmake script profiler
Hi Jean-Christophe, Thanks for the suggestion. We'll definitely consider it. -- Volo Zyko On Thu, Apr 25, 2013 at 12:23 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Volo, If you are doing some topological sorting to build your library/executable in the right order. Instead of using CMake based solution, you could may be rely on a C++ approach ? This is what we are doing in CTK. We are using a small prog named ctkDependencyGraph that we build at configure time. See [1-4] [1] http://www.commontk.org/index.php/Documentation/BuildSystem_Description [2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717 [3] https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake [4] https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150 On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko volo.z...@gmail.com wrote: We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world). However, I finished (more or less) the script for building time stats from the cmake's trace and we (with my colleague) found the slowest part. In our cmake scripts we have a bunch of sub-projects which produce libraries and also we have an utility function with which we define dependencies between those sub-projects. Then we define executables and build a list of libraries in a right order (from more dependent to less dependent) using sub-project's dependencies. This list is necessary for linking the executables. So, it appears that the slowest part is the function that builds the list of libraries. Basically there is nothing wrong with that cmake function, it just intensively works with strings. :( And here is where I put my script: https://code.google.com/p/cmake-profile-stats/ Comments are welcome. Also it looks like there are few bugs in the trace functionality of cmake; especially how callstack changes when cmake process foreach and if/else calls. I just didn't investigate them and I cannot provide more details. Sorry. -- Volo Zyko On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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 -- +1 919 869 8849 -- 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
Re: [CMake] cmake script profiler
Hi, If it turns out to be usefull for you. We could also consider creating a dedicated github project to avoid code duplication. That way you would be able to either add it as a git submodule to your project or checkout this new small project at configure time [1] Hth Jc [1] http://cmake.3232098.n2.nabble.com/is-it-possible-to-download-CMake-modules-at-configure-time-td7583968.html On Wed, Apr 24, 2013 at 5:32 PM, Volo Zyko volo.z...@gmail.com wrote: Hi Jean-Christophe, Thanks for the suggestion. We'll definitely consider it. -- Volo Zyko On Thu, Apr 25, 2013 at 12:23 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Volo, If you are doing some topological sorting to build your library/executable in the right order. Instead of using CMake based solution, you could may be rely on a C++ approach ? This is what we are doing in CTK. We are using a small prog named ctkDependencyGraph that we build at configure time. See [1-4] [1] http://www.commontk.org/index.php/Documentation/BuildSystem_Description [2] https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L691-717 [3] https://github.com/commontk/CTK/blob/master/CMake/ctkFunctionGenerateDGraphInput.cmake [4] https://github.com/commontk/CTK/blob/master/CMake/ctkMacroValidateBuildOptions.cmake#L127-150 On Wed, Apr 24, 2013 at 5:13 PM, Volo Zyko volo.z...@gmail.com wrote: We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world). However, I finished (more or less) the script for building time stats from the cmake's trace and we (with my colleague) found the slowest part. In our cmake scripts we have a bunch of sub-projects which produce libraries and also we have an utility function with which we define dependencies between those sub-projects. Then we define executables and build a list of libraries in a right order (from more dependent to less dependent) using sub-project's dependencies. This list is necessary for linking the executables. So, it appears that the slowest part is the function that builds the list of libraries. Basically there is nothing wrong with that cmake function, it just intensively works with strings. :( And here is where I put my script: https://code.google.com/p/cmake-profile-stats/ Comments are welcome. Also it looks like there are few bugs in the trace functionality of cmake; especially how callstack changes when cmake process foreach and if/else calls. I just didn't investigate them and I cannot provide more details. Sorry. -- Volo Zyko On Wed, Apr 24, 2013 at 10:14 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 4/24/2013 3:07 PM, Volo Zyko wrote: Hi, We use Makefiles on Linux and MacOS. Windows is not our target platform. From what we see Linux is the fastest. We made few attempts of building our project on Windows in VS but it was very-very slow and definitely cmake generates too many project files for VS. For us it was 500+ projects in a workspace which is too much for Visual Studio. :( Chances are you have too many high level targets in your project. What types of targets do you have? Are they all executables and libraries or are you using custom targets to do something? That might be a source of your performance issues as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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 -- +1 919 869 8849 -- +1 919 869 8849 -- 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
Re: [CMake] cmake script profiler
On 4/24/2013 5:13 PM, Volo Zyko wrote: We have executables and libraries and a lot of custom targets (the project is organized so that we export headers during the build - not the best idea in the world) Can you consolidate them into larger custom targets that use custom commands instead? add_custom_target(create_a_header COMMAND ...) # lots of these are bad add_custom_target(create_all_headers) add_custom_command(...) # lots of these that are part of the one target is good add_custom_command(...) Should even make your makefiles faster. -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
[CMake] cmake script profiler
Hi all,
We have a rather big project and use cmake for building it. At some point
our cmake scripts became very slow (around 4 minutes for single cmake run).
We are thinking now how to speed up it. Searching the web and this list
didn't give any results. It looks like there is no such thing as profiler
for cmake scripts. Am I right?
What about adding such capability to cmake? It looks like cmake's trace
provides enough info for time profiling, the only thing that it lacks is a
time stamp. Below is a small patch that adds time stamp and nesting level
(to simplify building a stack trace) to each trace line. Would it be
possible to integrate this change to the main line or are there better
options for time profiling of cmake?
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..0e6725c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace
backtrace) const
void cmMakefile::PrintCommandTrace(const cmListFileFunction lff)
{
cmOStringStream msg;
+ msg ( std::fixed cmSystemTools::GetTime();
+ msg ) ( this-CallStack.size() ) ;
msg lff.FilePath ( lff.Line ): ;
msg lff.Name (;
for(std::vectorcmListFileArgument::const_iterator i =
--
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
Re: [CMake] cmake script profiler
On 4/23/2013 3:50 PM, Volo Zyko wrote: Hi all, We have a rather big project and use cmake for building it. At some point our cmake scripts became very slow (around 4 minutes for single cmake run). We are thinking now how to speed up it. Searching the web and this list didn't give any results. It looks like there is no such thing as profiler for cmake scripts. Am I right? What about adding such capability to cmake? It looks like cmake's trace provides enough info for time profiling, the only thing that it lacks is a time stamp. Below is a small patch that adds time stamp and nesting level (to simplify building a stack trace) to each trace line. Would it be possible to integrate this change to the main line or are there better options for time profiling of cmake? That's funny. I was just playing around with adding a profile option. My approach was to sum up all the time spent in each function. It does not have a call stack but, should give you an idea of where it is spending the bulk of the time. I suppose you could post process the output of a trace with your change, but that would be more work. An example of my output on the ParaView project: 4.881 export 4.97701 vtk_wrap_python 5.15999 vtk_module_export 5.45701 VTK_WRAP_ClientServer 5.817 QT4_GET_MOC_FLAGS 6.159 vtk_module_impl 6.38601 pv_pre_wrap_vtk_mod_cs 7.08994 if 7.23499 vtk_add_python_wrapping 7.46001 QT4_WRAP_CPP 7.71494 configure_file 8.59399 vtk_module_config 8.904 pv_process_plugins 8.987 vtk_add_cs_wrapping 9.64503 set 11.654 try_compile 12.748 vtk_module_third_party 17.007 vtk_module_library 37.773 _vtk_module_config_recurse 112.788 include 158.092 add_subdirectory Also, thinking of adding some stats to number of times a variable is set and how many variables are used. -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
Re: [CMake] cmake script profiler
Hi Bill, Would it be possible to share the topic implementing your profiling code ? By default, summing the time spent in each functions makes sens. That said, it would also be nice to have the option of having detailed trace info, coupled with convenient code like message(START_PROFILING) and message(STOP_PROFILING), it would allow to get stats on a subset of the configure step. Having stats per directory would also be nice. Leveraging GUI like KCacheGrind [1] to visualize the profiling files could also be an option. Thanks Jc [1] http://kcachegrind.sourceforge.net/html/Shot3Large.html On Tue, Apr 23, 2013 at 4:24 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/23/2013 3:50 PM, Volo Zyko wrote: Hi all, We have a rather big project and use cmake for building it. At some point our cmake scripts became very slow (around 4 minutes for single cmake run). We are thinking now how to speed up it. Searching the web and this list didn't give any results. It looks like there is no such thing as profiler for cmake scripts. Am I right? What about adding such capability to cmake? It looks like cmake's trace provides enough info for time profiling, the only thing that it lacks is a time stamp. Below is a small patch that adds time stamp and nesting level (to simplify building a stack trace) to each trace line. Would it be possible to integrate this change to the main line or are there better options for time profiling of cmake? That's funny. I was just playing around with adding a profile option. My approach was to sum up all the time spent in each function. It does not have a call stack but, should give you an idea of where it is spending the bulk of the time. I suppose you could post process the output of a trace with your change, but that would be more work. An example of my output on the ParaView project: 4.881 export 4.97701 vtk_wrap_python 5.15999 vtk_module_export 5.45701 VTK_WRAP_ClientServer 5.817 QT4_GET_MOC_FLAGS 6.159 vtk_module_impl 6.38601 pv_pre_wrap_vtk_mod_cs 7.08994 if 7.23499 vtk_add_python_wrapping 7.46001 QT4_WRAP_CPP 7.71494 configure_file 8.59399 vtk_module_config 8.904 pv_process_plugins 8.987 vtk_add_cs_wrapping 9.64503 set 11.654 try_compile 12.748 vtk_module_third_party 17.007 vtk_module_library 37.773 _vtk_module_config_recurse 112.788 include 158.092 add_subdirectory Also, thinking of adding some stats to number of times a variable is set and how many variables are used. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- 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
Re: [CMake] cmake script profiler
On Wed, Apr 24, 2013 at 12:07 AM, Bill Hoffman bill.hoff...@kitware.com wrote: That's funny. I was just playing around with adding a profile option. My approach was to sum up all the time spent in each function. It does not have a call stack but, should give you an idea of where it is spending the bulk of the time. I suppose you could post process the output of a trace with your change, but that would be more work. I have a Python script that processes the cmake trace and creates stack traces. I'm polishing it right now and I'm planning to make it public on github or other similar service. No matter whether my patch for cmake will be accepted or not the script might be useful for other people. -- Volo Zyko -- 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
