On Wednesday 18 October 2006 08:05, Al Viro wrote:
> That's the point, actually - apparently we have several high-impact includes
> that are easy to sever and that are really worth being severed. The part
> that was not aproiri obvious:
> * there are clusters of headers around certain dependency
> counts.
> * such clusters tend to have leaders - header that pulls the
> rest and even though other headers are apparently independently included,
> all such includes end up being hidden by includes of the leader.
> * gaps between the clusters are pretty large.
> * dependency graph *on* *clusters* is worth being studied; includes
> of cluster leader from cluster around slightly smaller dependency count
> are prime targets for severing.
>
> That is the new part here. Not just "dependency graph is a mess and ought
> to be cleaned up" - _that_ is neither new nor particulary useful...
Well, logically for any given .config a set of all kernel header files
define a set of typedefs, structs, functions and so on.
If only we can read and parse them just once, and then reuse
already parsed information when we compile each .c file -
that will give you the biggest time savings.
gcc has some facility for that ("precompiled headers")
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
I don't know how hard it will be to adapt build system to using that
and there is a danger that using this thing will increase
recompile times when you change just a few CONFIG_XXXs.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
