From owner-freebsd-current@FreeBSD.ORG Wed Apr 14 18:18:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A11CE16A4D0 for ; Wed, 14 Apr 2004 18:18:13 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B6B843D41 for ; Wed, 14 Apr 2004 18:18:13 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (7d3cfdb85184ee395c0d73d03be435a8@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i3F1IBt5015184; Wed, 14 Apr 2004 18:18:11 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 50DC352322; Wed, 14 Apr 2004 18:18:10 -0700 (PDT) Date: Wed, 14 Apr 2004 18:18:10 -0700 From: Kris Kennaway To: Garance A Drosihn Message-ID: <20040415011809.GA58644@xor.obsecurity.org> References: <20040413121925.GB29867@voodoo.oberon.net> <407C4035.8020609@ciam.ru> <1081896823.772.58.camel@klotz.local> <20040414131949.3A56E43D31@mx1.FreeBSD.org> <20040414232927.GA56961@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current cc: Robin Schoonover cc: Kris Kennaway Subject: Re: Second "RFC" on pkg-data idea for ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 01:18:13 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2004 at 09:09:36PM -0400, Garance A Drosihn wrote: > At 4:29 PM -0700 4/14/04, Kris Kennaway wrote: > >On Wed, Apr 14, 2004, Robin Schoonover wrote: > > > > > > I use make -V a lot, and it's slow (every time you run it, make > > > has to reread all the bsd.*.mk files, such as bsd.port.mk). The > > > speed isn't much of an issue when you only do one or two ports, > > > but when you are examining the entire ports collection, you notice. > > > > >> That said, I'd still rather use a makefile based ports system anyway. > > > >Necessarily, *any* file format you choose will need to parse > >auxilliary files analogous to bsd.port.mk. There's just no getting > >around the fact that ports rely on a lot of infrastructure and > >conditional evaluation to set their variables (although it can be > >optimized relative to what we have in CVS today [1]). > > > >Note that it's intentional that a lot of things are centralized > >in bsd.port.mk where they may be easily maintained, instead of > >being set in 10000 individual makefiles. > > > >Kris > > > >[1] As a test, I recently was able to cut index build times by > >60% from 5 to a little over 2 minutes on test box with fast disks, > >by stripping out (almost) everything non-essential from the 'make > >describe' code path. >=20 > Personally, I think you can get quite a penalty by trying to > perform too much string-manipulation by using make/sh variables > combined with all kinds of fancy invocations of sed, awk, etc. > In other situations (which are totally unrelated to ports), I > have greatly improved performance of some operation by replacing > some clever shell scripts with ruby or perl. Neither of those > are speed demons compared to C, but they make a huge difference > for something which is using sed/awk for lots of low-level string > manipulation. >=20 > My hope is that if I get far enough along into the pkg-data project, > the result would be that many of the common operations would be > faster. However, right now I can only say "that is one of my > goals", and I can't prove it would actually happen... There's only a few things that execute external commands in the common code path of port makefiles. I've been working hard to remove or limit them, and as I mentioned above it's possible to optimize the current framework a lot further without too much hard work. Kris --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAfeLRWry0BWjoQKURArboAJ4vA26+UpDPAP0Mt9rczKtudjpBAACePRsu hsf7L7hZIcN6yk7xe5g0sSQ= =o5t3 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--