> X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, > DNS_FROM_RFC_POST,UNPARSEABLE_RELAY autolearn=no version=3.1.0 > Date: Thu, 11 Jun 2009 22:27:48 -0400 > From: Mike Shal <[email protected]> > Cc: [email protected] > > On 6/11/09, grischka <[email protected]> wrote: > > Mike Shal wrote: > > > > > > > For some hard numbers, my > > > machine takes 17s to run make in an already-built linux kernel tree. > > > Just doing a 'find . | xargs stat > /dev/null' only takes 2.6s though, > > > so I would guess the remaining ~14s are mostly for parsing Makefiles > > > and processing the DAG. > > > > > > > Careful with conclusions from "hard numbers". > > Fair point :) > > > > > Consider that in comparison to "17s to run make in an already-built linux > > kernel tree", TCC needs ~15 seconds to COMPILE AND LINK the entire linux > > kernel tree -> http://bellard.org/tcc/tccboot.html. That > > at least shows > > that no program would spend that "~14s" just to read some Makefiles or > > loop over some linked lists (i.e. "processing the DAG"). > > I've never heard of TCC - I'll have to check it out! Though my point > was merely that make is doing *something* during those 17s, none of > which is useful to me since no files have actually changed in the > kernel tree. The stat()ing is just a rough estimate of that portion of > make's execution time. Is there a better way to benchmark it to figure > out the bottlenecks? > > > After all GNU make is not "the reference implementation of an alpha build > > system". It is a piece of code with a long history with more going on > > than just a few O(n) lookups. You might find features like checkout > > from RCS/SCCS version control via built-in rules which is obsolete stuff > > since long ago, still everyone using GNU make today is paying for it with > > maybe 80% of it's total CPU time, worldwide. (Try "make -r ..." to see > > what I mean). > > Yeah, I've seen some pages that document how to get rid of a bunch of > that built-in stuff (there were a few patterns you had to add to a > Makefile as well, if I recall correctly). Has anyone done benchmarks > on that to see what kind of overhead that actually accounts for? > > > Anyway, good luck with TUP, I'll try it out. And waiting for your new > > "beta CONFIGURE system", if any possible one that doesn't rely on > > megabytes of unmaintainable shell scripts ... ;) > > Thanks! I might want to leave the configure system to someone else, though :) > > -Mike > > > _______________________________________________ > Help-make mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/help-make >
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
