From owner-freebsd-ports@FreeBSD.ORG Mon Aug 1 05:57:36 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CCBBD106566B; Mon, 1 Aug 2011 05:57:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A08A914EB5A; Mon, 1 Aug 2011 05:57:34 +0000 (UTC) Message-ID: <4E36404C.9090109@FreeBSD.org> Date: Sun, 31 Jul 2011 22:57:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110723 Thunderbird/5.0 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4E345DBD.1090503@FreeBSD.org> <4E34B0BB.9050008@FreeBSD.org> <4E353A46.1050204@FreeBSD.org> <4E35A998.5060102@FreeBSD.org> <4E35ADA3.40401@FreeBSD.org> <4e369765.T+NLcZoj2rV7wQkF%perryh@pluto.rain.com> In-Reply-To: <4e369765.T+NLcZoj2rV7wQkF%perryh@pluto.rain.com> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-gnome@freebsd.org, freebsd-ports@freebsd.org, avg@freebsd.org Subject: Re: UPDATING 20110730 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 05:57:36 -0000 On 08/01/2011 05:09, perryh@pluto.rain.com wrote: > Andriy Gapon wrote: > >> If for X ports all the relevant data under /var/db/pkg fits into >> fs cache, then the performance may be blazing, but once you exceed >> the cache size the performance might become totally different. > > and/or the poorly-performing system may have enough less memory than > the other for paging/swapping to be a factor. I may not be the smartest guy in the project, but I think that you(pl.) can reasonably assume that I understand something as fundamental as "data set fits in RAM means it goes fast." :) You can also safely assume that I understand that if portmaster's work causes the cache to overflow, or the user gets stuck behind a combination of slow disk and/or a small amount of RAM that performance is going to suck. My point was simply that there isn't anything I can do about it. Making sure that the +CONTENTS and +REQUIRED_BY files are up to date is an important part of portmaster's core functionality. Unfortunately the only way to improve on this would be to not do the checks on a port-by-port basis, and do them all together at the end. While that sounds appealing, it would dramatically increase the code complexity, and also dramatically increase the chances of leaving the pkg files in an inconsistent state if the process gets interrupted. I don't like either one of those options. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/