From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-64301-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 18DBF138247
for <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Mon, 13 Jan 2014 16:49:19 +0000 (UTC)
Received: by mail-wi0-f179.google.com with SMTP id hi5so1384039wib.12
for <gentoo-dev@lists.gentoo.org>; 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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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>
<CAN3AtvqZyWsLethMUPBbh7B3zVvHSgN+kN63uynkDvef__1rCg@mail.gmail.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: <CAAr7Pr-cyvnvv8useujRQBhRd-UNvTgUemyk7b+9ko=eiMBLMw@mail.gmail.com>
Subject: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
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 <aranea@aixah.de> wrote:
> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
>
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani <lxnay@gentoo.org> 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 <aranea@aixah.de>
> 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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 13, 2014 at 7:38 AM, Luis Ressel <span dir=3D"ltr"><<a href=3D"m=
ailto:aranea@aixah.de" target=3D"_blank">aranea@aixah.de</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, 13 Jan 2014 15:58:13 +0100<br>
Tom Wijsman <<a href=3D"mailto:TomWij@gentoo.org">TomWij@gentoo.org</a>&=
gt; wrote:<br>
<br>
> On Mon, 13 Jan 2014 10:31:56 +0100<br>
> Fabio Erculiani <<a href=3D"mailto:lxnay@gentoo.org">lxnay@gentoo.o=
rg</a>> wrote:<br>
><br>
> > Portage can still take *minutes* to calculate the merge queue of =
a<br>
> > pkg with all its deps satisfied.<br>
><br>
> Half a minute if you disable backtracking which you don't need. :)=
<br>
<br>
</div>Which sadly also means that some updates get skipped silently. (Those=
<br>
which would trigger rebuilds of other packages because of sub-slot<br>
deps, had that case yesterday).<br>
<div class=3D"im"><br>
> > Ironically, launching the same emerge command twice, will take mo=
re<br>
> > or less the same time.<br>
><br>
> Determinism results in more or less the same time, that's correct;=
<br>
> proper benchmarks would show you a similar result.<br>
<br>
</div>I guess he means that the (according to the file sizes) extensive<br>
caching doesn't seem to be of much use.<br></blockquote><div><br></div>=
<div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div><div>-A</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Luis Ressel <<a href=3D"mailto:aranea@aixah.de">aranea@aixah.de</a>><=
br>
GPG fpr: F08D 2AF6 655E 25DE 52BC =C2=A0E53D 08F5 7F90 3029 B5BD<br>
</font></span></blockquote></div><br></div></div>
--089e01176ee34d2ff904efdcdb91--