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 18DBF138247 for ; Mon, 13 Jan 2014 16:49:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F12BE0B04; Mon, 13 Jan 2014 16:49:20 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3B17DE0AFC for ; Mon, 13 Jan 2014 16:49:19 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hi5so1384039wib.12 for ; Mon, 13 Jan 2014 08:49:18 -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:date :message-id:subject:from:to:content-type; bh=0EbnuaaiijpAiLh2ceJC+sLLYf8M2y4XWlvd7MSqKOg=; b=Dm7T10U3IwgpaZTzmkUTW+ZAGzIsn6LrdZMG3V+k8TZLm+HYaN+CcD9J9QuBpcma8G Fr6Zqh8fe+oH4N4xa9ZzWNcfxYg4xlD68/fg7rM2lpjRmKs6x1ZkVonyj20JsGMTTKLz DoCfCblho2mAXWpLQHePkDD265iddvZgK5pyWh0IeCSeRKB02jbpbdpZCU4sJlhoGf2b /rNZqJW25RhV/Cd1pEd58akNxJYRoBZf6C5kfkClUtAzrT660IkFzFU+UKkpXIz/0jmn w2ZjxVfXjjHuJnBh1c+8FL9OKLyymDKqivdWIFVQ9XQoOZ3e/8Vg5qh/iottCvT+4gK7 ZcxQ== X-Gm-Message-State: ALoCoQnw/l/D0k9mMEVpSJyxQ+sFiKOVO8nKUwiC29amSLBqjC5g25OFv+ch5wjblIUmQWFlNgJ3 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 X-Received: by 10.194.142.174 with SMTP id rx14mr22476739wjb.45.1389631757949; Mon, 13 Jan 2014 08:49:17 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.216.170.129 with HTTP; Mon, 13 Jan 2014 08:49:17 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: <20140113163859.61c3df01@gentp.lnet> 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> Date: Mon, 13 Jan 2014 08:49:17 -0800 X-Google-Sender-Auth: rCv1gzEwEj83WxFz_oiJ-ACKbr4 Message-ID: Subject: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=089e01176ee34d2ff904efdcdb91 X-Archives-Salt: 22dbfe5d-38e0-4346-80cb-80d2033b83eb X-Archives-Hash: dc8f80a7952109a67d5fbb5181e3b41f --089e01176ee34d2ff904efdcdb91 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel wrote: > On Mon, 13 Jan 2014 15:58:13 +0100 > Tom Wijsman wrote: > > > On Mon, 13 Jan 2014 10:31:56 +0100 > > Fabio Erculiani wrote: > > > > > Portage can still take *minutes* to calculate the merge queue of a > > > pkg with all its deps satisfied. > > > > Half a minute if you disable backtracking which you don't need. :) > > Which sadly also means that some updates get skipped silently. (Those > which would trigger rebuilds of other packages because of sub-slot > deps, had that case yesterday). > > > > Ironically, launching the same emerge command twice, will take more > > > or less the same time. > > > > Determinism results in more or less the same time, that's correct; > > proper benchmarks would show you a similar result. > > I guess he means that the (according to the file sizes) extensive > caching doesn't seem to be of much use. > The caching may not be of use, depending on your configuration. (For example, if you use a gentoo-x86 checkout as your main repo, you will probably want to run generate cache entries whenever you cvs up.) It is there to cache ebuild metadata, because if your depgraph has a few thousand nodes, having to spawn bash to generate the metadata for every node is very expensive. That being said, for most users that use rsync, the metadata is pre-generated. As long as they are not changing the cache indicators (not sure if this is mtime or md5sum these days) they should be seeing a benefit. 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.) -A > > -- > Luis Ressel > GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > --089e01176ee34d2ff904efdcdb91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 13, 2014 at 7:38 AM, Luis Ressel <aranea@aixah.de> wro= te:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman <TomWij@gentoo.org&= gt; wrote:

> On Mon, 13 Jan 2014 10:31:56 +0100
> Fabio Erculiani <lxnay@gentoo.o= rg> wrote:
>
> > Portage can still take *minutes* to calculate the merge queue of = a
> > pkg with all its deps satisfied.
>
> Half a minute if you disable backtracking which you don't need. :)=

Which sadly also means that some updates get skipped silently. (Those=
which would trigger rebuilds of other packages because of sub-slot
deps, had that case yesterday).

> > Ironically, launching the same emerge command twice, will take mo= re
> > or less the same time.
>
> Determinism results in more or less the same time, that's correct;=
> proper benchmarks would show you a similar result.

I guess he means that the (according to the file sizes) extensive
caching doesn't seem to be of much use.

=
The caching may not be of use, depending on your configuration. (For e= xample, if you use a gentoo-x86 checkout as your main repo, you will probab= ly want to run generate cache entries whenever you cvs up.) It is there to = cache ebuild metadata, because if your depgraph has a few thousand nodes, h= aving to spawn bash to generate the metadata for every node is very expensi= ve. That being said, for most users that use rsync, the metadata is pre-gen= erated. As long as they are not changing the cache indicators (not sure if = this is mtime or md5sum these days) they should be seeing a benefit.

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 se= e Tomwij turning off that feature. It is helpful for users cause it can aut= omatically find solutions for users that are otherwise unsolvable (and thus= avoids the user having to find a solution to the depgraph manually.)

-A



--
Luis Ressel <aranea@aixah.de><= br> GPG fpr: F08D 2AF6 655E 25DE 52BC =C2=A0E53D 08F5 7F90 3029 B5BD

--089e01176ee34d2ff904efdcdb91--