[cmake-developers] dependency scanning speed

[Alexander Neundorf]

On Sunday 10 September 2006 10:55, Alexander Neundorf wrote:
> On Sunday 10 September 2006 09:19, Alexander Neundorf wrote:
> > On Sunday 10 September 2006 01:19, you wrote:
> > ...
> >
> > > did you use valgrind's callgrind tool to profile this? I think you'll
> > > really get more concrete data on what's taking up the most time by
> > > using that tool. :)
> >
> > Not yet.
> > From my knowledge of this code, this is basically a lot of dealing with
> > STL strings and string containters and some stat()ing.
> > I would guess that one must try to reduce the work actually done by
> > caching even more information.
>
> "some stating" was slightly wrong it seems.
> Here are the numbers:
> -each source files is stat()ed once, gives 1921 stat()
> -the includecache files are stated once for each source file. give 1858
> stat() -> these could be reduced to 2 stat() calls, would save 1856 stat(),
> not *that* much
> -495,388 access() calls with relative paths, might be tricky to cache
> -2,851,201 access() calls with absolute paths for 27,666 different paths,
> should be easy to cache. This would remove 2,823,535 access() calls.
>
> /me goes testing

Ok, caching the results of access() in a std::map<string, bool> saved the 2,8 
million access() calls, but nevertheless it made things worse, time went up 
from 28 to 30 seconds. Probably the malloc() for the 27,000 strings in the 
map.
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 ?

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