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 A9371138247 for ; Mon, 13 Jan 2014 17:11:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9308E0B18; Mon, 13 Jan 2014 17:11:14 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BC97AE0AD3 for ; Mon, 13 Jan 2014 17:11:13 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id u56so4444819wes.26 for ; Mon, 13 Jan 2014 09:11:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=+4LotiBGpSwCCom+qdgoqj8grjAbBBAp24iSBny3UcI=; b=alnB+gNcDbaodKU2tM9kTb+fpvcY7L6wnfSCuIH31VmP12XTpcEqNnpSOcISfNoqCg bGhgwf53jL7FudCB8z24VkRK/Gs4LFZUws0M3/2OjN4A2hcj/I3FW0hG8FR3wI6gv4py NrHPuQqqcBy2Hr6ZwePcHNK8ek5UbvTOBhtlcB93jaRex7y6jD4X77MgjoPLkJ8LptkE W4vXouy033hfCsEtRxNaXl0N3lMjo3kRcZmG7VbkzEaMHqt/n3m27e1hjxlB5NtVt/qQ 0mrSqY5LVec83cX9Nrg1fZyRmVv66zfHCuszOsf/GpXnUZbNgQq19W4HyBk8Jihkvxjz fzvQ== X-Gm-Message-State: ALoCoQnnul2sbacKIRsD+d6UwlrdDIerKaaBwG2oMKI90lajAsGBS4ZGEnWqIaDhIJVeznHyyaax X-Received: by 10.194.175.202 with SMTP id cc10mr23055346wjc.48.1389633072251; Mon, 13 Jan 2014 09:11:12 -0800 (PST) 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 Sender: lxnay@sabayonlinux.org Received: by 10.194.83.193 with HTTP; Mon, 13 Jan 2014 09:10:32 -0800 (PST) In-Reply-To: References: <1388986435.17870.49.camel@big_daddy.dol-sen.ca> <1389582464.7103.185.camel@big_daddy.dol-sen.ca> <20140113083917.5427344.53422.41690@pathscale.com> <52D3A71F.9040602@plaimi.net> <52D3AEB9.7080500@pathscale.com> <20140113155813.391c403f@TOMWIJ-GENTOO> <20140113163859.61c3df01@gentp.lnet> From: Fabio Erculiani Date: Mon, 13 Jan 2014 18:10:32 +0100 X-Google-Sender-Auth: VMOlJLmHUk25Cn4bj3jbbCLcNo0 Message-ID: Subject: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: df0a7e38-e434-47dc-8e53-25e4d00210c9 X-Archives-Hash: c892114b707c5b346e1903da9431b66b On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner wrote: [...] > > This is not meant to imply that portage is always fast; there are plenty of > other modules (such as the aforementioned backtracking) that can take a long > time to find solutions. That is partially why you see Tomwij turning off > that feature. It is helpful for users cause it can automatically find > solutions for users that are otherwise unsolvable (and thus avoids the user > having to find a solution to the depgraph manually.) Yeah, correct. But it would be nice if Portage backtrack_depgraph() would memoize (asynchronously serializing to disk, for instance) partial results for later use. AFAIR, last time I checked, it wasn't doing that. Also, it would be nice if the aux_db cache of the vdb could be stored in a sqlite3 db rather than in RAM. This dict is consuming a huge cut of memory for little reason (a single vdb.dbapi.match() can eat 100MB of RAM). We know how Python deals with freed memory... Sigh... > > -A > >> >> >> -- >> Luis Ressel >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > > -- Fabio Erculiani