From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j3SLRnrO017208 for ; Thu, 28 Apr 2005 21:27:49 GMT Received: from adsl-67-39-48-198.dsl.milwwi.ameritech.net ([67.39.48.198] helo=exodus) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DRGY1-0003V4-3F for gentoo-dev@lists.gentoo.org; Thu, 28 Apr 2005 21:27:49 +0000 Date: Thu, 28 Apr 2005 16:28:31 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Portage ebuild cruft Message-ID: <20050428212831.GA26379@exodus.wit.org> References: <200504281840.23788.lanius@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504281840.23788.lanius@gentoo.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: fd71ab05-9521-4401-894c-e929cc1514fc X-Archives-Hash: 697660cece574804fa6f12d0e58694d6 On Thu, Apr 28, 2005 at 06:40:23PM +0200, Heinrich Wendel wrote: > Hi, > > Portage is slow? How to make it faster? By removing unused ebuilds! Define "faster". All this would do is cut down on a couple of stats per pkg; the # of ebuilds per pkg isn't a huge issue, the scanning of vdb and Config initialization is what is damned slow. :) > I wrote a little script to check which ebuilds in portage aren't used > anylonger, here the result: > > Total packages checked: 9076 > Total ebuilds checked: 18662 > Total ebuilds to remove: 4643 Dropping every ebuild that isn't the highest version for the mismash of arches isn't really valid. Granted, people *could* stand to do cleansing of old versions in the tree, but the versions they choose to support/offer is completely up to the ebuild dev. > Of course the script can't detect every ebuild situation, so take the numbers > with care. But still it shows that 1/4 of all ebuilds could be removed. This > would improve portage performance by at least 1/4 Again, define what aspect of portage performance. The only thing less ebuilds cuts down on is the avg runtime of a cp_list call; cache is keyed, so lookup is *typically* constant. ~brian -- gentoo-dev@gentoo.org mailing list