header dependency scanning

From: Alexey Syomichev (asyomichev_at_[hidden])
Date: 2005-05-03 16:04:42

I believe that header dependency scanning results used to be cached
between bjam runs. I also remember that at some point the caching was
disabled because it didn't show any speed advantage over re-scanning.
Is this really the case for any level of the performance of a file
system hosting the project?
I think I might have a case when caching would be beneficial. I have a
relatively large project living on a relatively slow NFS system. For a
build started from the root of the project, it takes about 3
(frustrating) minutes of "...patience..." before the first update
action command, and bjam finds about 34000 targets.
The output of "bjam –d+10", sorted by the net time, shows
that the header scanning takes a significant portion of that time (see
below).
Is it hard to put header dependency information caching back?
Also, in my case a large number of 3rd party headers account for about
3/4 of targets found by bjam, and for about 2/3 of scanning time. A
feature that would allow excluding certain directories from header
dependency scanning would be extremely useful. Does anybody else share
this opinion?

Here is the top portion of sorted bjam –d+10:
gross net # entries	name
19072000 8126000 25588	class_at_c-scanner.process
5506000	4821000	51176	regex.transform
4431000	4431000	25588	scanner.propagate
3959000	3959000	50183	feature.valid
2875000	2875000	716	CHECK_IF_FILE
44618000	2650000	152	modules.load
6376000	2484000	1584	class_at_property-set.__init__
2272000	2272000	2492	GLOB
20807000	1735000	25588	scanner.hdrrule
1403000	1403000	296682	MATCH
10502000	1169000	9491	class.new
4795000	965000	48771	feature.attributes
1166000	962000	8364	regex.split