From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E39CC1381F3 for ; Sun, 16 Jun 2013 21:57:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C6C0E0957; Sun, 16 Jun 2013 21:57:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3A952E08C0 for ; Sun, 16 Jun 2013 21:57:35 +0000 (UTC) Received: from [192.168.26.7] (ip98-164-195-43.oc.oc.cox.net [98.164.195.43]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 6736B33E292 for ; Sun, 16 Jun 2013 21:57:34 +0000 (UTC) Message-ID: <51BE34CC.3090906@gentoo.org> Date: Sun, 16 Jun 2013 14:57:32 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Packages up for grabs References: <1371376191.10717.15.camel@localhost> <1371390923.28535.67.camel@big_daddy.dol-sen.ca> <20130616164445.0c8f8f55@TOMWIJ-GENTOO> <1371402560.28535.79.camel@big_daddy.dol-sen.ca> <1371403298.22480.8.camel@localhost> <20130616202324.45cb3262@TOMWIJ-GENTOO> In-Reply-To: <20130616202324.45cb3262@TOMWIJ-GENTOO> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 39e4588b-1d35-497a-8f1e-269e1f40d666 X-Archives-Hash: 9879d41e327ac020a27984dc94626bdf On 06/16/2013 11:23 AM, Tom Wijsman wrote: > Ignoring that call graph, you could look at what has recently been > introduced to increase the amount of time needed to calculate the > dependency graph; you don't have to look far. > > http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/ > > While I don't want point out the contents of that blog post, the title > is relevant; implementing features like subslots on an algorithm that > was not written with subslots in mind introduces a lot of inefficiency. It's actually not bad, since all of the subslot rebuilds are triggered in a single backtracking run. Anyway, I welcome having people work on competing package managers, trying to do all of this stuff more efficiently. :-) > And it's not just subslots, newer features keep getting added to the > dependency graph calculation and it gets slower and slower over time. > It feels like revdep-rebuild moved into the dependency calculation! I guess the main things that make it slower than it has been historically would be things like --autounmask, --backtrack, --complete-graph-if-new-use and --complete-graph-if-new-ver. Note that you can use EMERGE_DEFAULT_OPTS to disable these things if you would prefer to live without them. You might use something like --backtrack=2 if you want it to bail out early for all but the simplest backtracking cases. Use --ignore-built-slot-operator-deps=y if you want to disable all rebuilds involving subslots and slot-operators. -- Thanks, Zac