[cmake-developers] dependency scanning speed
Alexander Neundorf
neundorf at kde.org
Sun Sep 10 11:41:02 EDT 2006
On Sunday 10 September 2006 17:07, Bill Hoffman wrote:
> At 05:58 AM 9/10/2006, Alexander Neundorf wrote:
> >I tried callgrind, but it doesn't work.
> >I have kubuntu, valgrind 3.0.1 and callgrind 0.10.1.
> >It starts and finishes after approx 3 seconds (instead of 30). 10 percent
> > of the time are spent in cmake, 50 in ld and 30 percent in libc. So it
> > seems cmake quits immediately after starting.
> >Any idea what's wrong ?
>
> Often times when the problem is due to disk access calgrind is not much
> help. The overhead of calgrind makes it so the disk can keep up with the
> process. The only way to debug, is it add timers in the code directly. So,
> it sounds like the problem is accessing all of those files.
I got callgrind working, it was a version problem between callgrind and
valgrind.
Since using a map<string, bool> cache to get rid of 2,5 million access() calls
didn't help but made things worse, it seems it's not the file IO which is
slow.
Now kcachegrind shows that 99 % are spent in WriteDependencies(), from which
53 % are spent in std::string operator+= and the std::string dtor.
I was able to get the time from 28 seconds down to 24 seconds, i.e. approx.
15% by replacing the std::string temp which is used when iterating through
the include dirs with a simple char buffer.
While 15 % doesn't sound bad, it's no perceivable difference.
I'll try to cache the location of the actual file so that not everytime all
include dirs have to be iterated.
Bye
Alex
--
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org - http://www.kde.org
alex AT neundorf.net - http://www.neundorf.net
More information about the cmake-developers
mailing list