From owner-freebsd-x11@FreeBSD.ORG Wed May 23 22:21:18 2007 Return-Path: X-Original-To: freebsd-x11@freebsd.org Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C966316A41F for ; Wed, 23 May 2007 22:21:16 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 6C12913C489 for ; Wed, 23 May 2007 22:21:16 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from [127.0.0.1] (Q7d08.q.ppp-pool.de [89.53.125.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 9A680128844; Thu, 24 May 2007 00:21:09 +0200 (CEST) Message-ID: <4654CC62.3060209@vwsoft.com> Date: Thu, 24 May 2007 00:21:06 +0100 From: Volker User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Kris Kennaway References: <4654BC62.5060405@vwsoft.com> <20070523212137.GA64003@xor.obsecurity.org> In-Reply-To: <20070523212137.GA64003@xor.obsecurity.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-x11@freebsd.org Subject: Re: ports performance X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 22:21:18 -0000 On 2007-05-23 22:21, Kris Kennaway wrote: > On Wed, May 23, 2007 at 11:12:50PM +0100, Volker wrote: >> Hi! >> >> I've lightly followed the ongoing discussion of enhancing the >> performance of the ports system. But I'm unable to come to any >> conclusion as one gives a patch, another one says it may break >> something. >> >> Just to throw in a few numbers into this discussion: >> >> 2 weeks ago I took the chance to upgrade a test machine >> (Ahtlon64-3400) and the machine was building ports for one or two >> days (it was mostly unattended so I'm unable to give correct >> values). Starting last sunday, I wanted to update my notebook (the >> machine I'm using every day) to the latest ports - including Xorg 7.2. >> >> I've had to abort port building today. After csup'ing the ports >> tree, ~360 (out of ~640) ports needed to be updated. >> >> As the frustration raised, I watched the machine performance and >> figured out, port registration takes up to 12 minutes. Overall port >> compilation is not an issue but the management of the ports database >> is way too slow. Imagine: around 360 ports, each port takes between >> 6 and 12 minutes for registration. Let's calculate each registration >> with only 6 minutes (most take more) that's 36 hours just for port >> registration (w/o compilation, directory cleaning). >> >> My notebook is a P4m-1.8GHz, 512 MByte system - shouldn't be too slow. >> >> So, what's the fast solution for the average desktop to this problem? >> >> Using top, I've seen ruby18 and pkg_create eat up a lot of cpu time. >> Will 'downgrade' portupgrade-devel to portupgrade help on this? >> >> To fix my notebook, I'm currently building packages on another >> system, will delete all Gnome/X7.2 ports and start from scratch. I'm >> afraid of the next major update (gnome comes to mind) if ports still >> will take that long. >> >> I will happily try beta testing fixes if they don't break anything. > > Of course that cannot be guaranteed. Beta testing implies willingness > to deal with possible bugs. If you are willing to help, that's great, > otherwise you'll have to put up with the slowness while others in the > community help. Kris, probably I took the wrong words but you got me wrong. Of course, I'm willing to spend time on investigating things or try to work around possible bugs. Which patches are the suggested ones (agreed by portsmgr developers) to try? It's not a portupgrade problem, isn't it? Volker