Re: Looking for speed increases in "make index"

On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
To gain some performance, a first idea would be to simplify
bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
are historical crap which serve no useful purpose.

11272 of LOC in bsd.*.mk, but who's counting.

There are tons of variables who have probably purely anecdotical
interest. There are targets which could be happily suppressed.

Please let us know which functionality you think is extra. You should
use the individual port Makefiles as well as ports/Makefile to figure
out what is unused. For extra credit, please include
ports/Tools/portbuild/scripts so the build cluster will continue to work.

Please don't think I am picking on you specifically; however, about every
6 months or so someone decides that "the ports framework is too complicated"
without saying exactly what needs to be removed. Since I look at all the
portmgr PRs as they come in, and participate in rejecting in some of the
(by our determination) more marginal features, I can assure you that not
every single new proposal makes it in there, nor has in the past. Every-
thing that's in there is because there was some specific justification for
it (at least at the time).

Given that we had no install base, a significant rewrite would not be a
burden, but that's not the case.

Please note, I've agreed for several years that a great deal of the code
could be factored out into some kind of C library for speed and reduction
of code duplication. Some work is going towards that in the Summer of Code.

But the hard part is making it work, in a backwards compatible fashion,
and doing the exhaustive regression testing to prove that it solves more
problems that it creates. (portmgr spends a _lot_ of time on regression
testing, behind the scenes.)

In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of constraints and conditions. I challenge
anyone who thinks things can be removed to roll up their sleeves and make
a good case for it. I'd be happy to have something easier to read.

mcl
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"