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 5CBD913800E for ; Mon, 3 Feb 2014 16:38:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3FAF4E0AD2; Mon, 3 Feb 2014 16:38:33 +0000 (UTC) Received: from sempidan.tirtonadi.com (unknown [69.65.40.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 425FBE0AA0 for ; Mon, 3 Feb 2014 16:38:30 +0000 (UTC) Received: from mail-vc0-f176.google.com ([209.85.220.176]:54420) by sempidan.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1WAMXV-00081F-Ou for gentoo-user@lists.gentoo.org; Mon, 03 Feb 2014 23:38:29 +0700 Received: by mail-vc0-f176.google.com with SMTP id la4so4840255vcb.21 for ; Mon, 03 Feb 2014 08:38:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9KHfb0fuwg3y7uTDMi5dQfwwZ3XCM7ByjQ26FR3zJKA=; b=G60FNUIV5VfMlPf2nEiaFrGuGymzqNniVdx1LXPHms74bs/j76fo34n+SxZ09qhYBG QRa4jGUgWQLTP+zm236VnF4c98XyhDsI33KQ4xFQ1laVJVdHxU4RGpHEda1/s8rlpVE9 U1gRk8qoaXbmu8cwEDzgZCWZQZxyKAVC7HvbmH07Ir8CQZlFgKV4lnUQZTL30zW6aInl 7Xyn/QWeAlZ08HqXD64JMrXGUY2T0iF0GC9oJwknMRRmjjqNtQTYyfLPaSGVMJFWSM2/ KR8pLvGrTHueOduJ0ofpeBEB4pyRX5kAZ6XF/HIBY2JyExLys9yw63VwLj062E0bCXV7 UbaA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.108.232 with SMTP id hn8mr2142221vdb.29.1391445507555; Mon, 03 Feb 2014 08:38:27 -0800 (PST) Received: by 10.220.12.205 with HTTP; Mon, 3 Feb 2014 08:38:27 -0800 (PST) Received: by 10.220.12.205 with HTTP; Mon, 3 Feb 2014 08:38:27 -0800 (PST) In-Reply-To: <52EFA4D9.9070905@gmail.com> References: <20140126162426.7a6d1f30@falcon.eroen.eu> <52E54920.5010207@gmail.com> <52E54E34.7080709@gentoo.org> <52E64A27.9090105@libertytrek.org> <52E659F1.1090508@gmail.com> <52E665B6.9030301@gentoo.org> <20140127214837.47278679@digimed.co.uk> <52E6D594.1010508@gentoo.org> <20140127225700.44fb0c81@hactar.digimed.co.uk> <52EFA4D9.9070905@gmail.com> Date: Mon, 3 Feb 2014 23:38:27 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Portage performance dropped considerably From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=bcaec5485b5233cb1904f18327ba X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sempidan.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: sempidan.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: d2e41d22-edf4-4c89-a34b-bfc25ed49b3e X-Archives-Hash: dbd716135e88db69d41bb87d5fae2ea5 --bcaec5485b5233cb1904f18327ba Content-Type: text/plain; charset=UTF-8 On Feb 3, 2014 9:17 PM, "Alan McKinnon" wrote: > > On 03/02/2014 16:04, Pandu Poluan wrote: > > > > On Jan 28, 2014 5:57 AM, "Neil Bothwick" > > wrote: > >> > >> On Mon, 27 Jan 2014 22:54:28 +0100, hasufell wrote: > >> > >> > >> If it's about performance (in the sense of speed), then paludis > >> > >> is worse, because dependency calculation is more complex/complete > >> > >> there. > >> > > > >> > > That makes no sense at all. Paludis is written in a different > >> > > language using different algorithms. It's not about the amount of > >> > > work it does so much as how efficiently it does it. > >> > >> > That's exactly what I was saying. I was talking about speed, not > >> > efficiency. > >> > >> But the efficiency of the algorithm, and the language, affects the speed. > >> You can't presume "it does more, therefore it takes longer" if the two > >> programs do things in very different ways. > >> > > > > I was thinking: is it feasible, to "precalculate" the dependency tree? > > Or, at least "preprocess" all the sane (and insane) dependencies to help > > portage? > > > I thought that's what the portage cache does, as far as it can. > > True, the cache reflects the state of the tree and not the parts of the > tree a given machine is using, so how big a diff does that give? And > don't forget overlays - they can slow things down immensely as more > often than not there's no cache for them unless the user knows to do it > manually. > Well, AFAIK, portage needs to kind of simulate everything going on in an ebuild to get the list of dependencies/blockers... If this can be 'pre-simulated' resulting in a simpler to parse 'database' of dependencies... Rgds, -- --bcaec5485b5233cb1904f18327ba Content-Type: text/html; charset=UTF-8


On Feb 3, 2014 9:17 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On 03/02/2014 16:04, Pandu Poluan wrote:
> >
> > On Jan 28, 2014 5:57 AM, "Neil Bothwick" <neil@digimed.co.uk
> > <mailto:neil@digimed.co.uk>> wrote:
> >>
> >> On Mon, 27 Jan 2014 22:54:28 +0100, hasufell wrote:
> >>
> >> > >> If it's about performance (in the sense of speed), then paludis
> >> > >> is worse, because dependency calculation is more complex/complete
> >> > >> there.
> >> > >
> >> > > That makes no sense at all. Paludis is written in a different
> >> > > language using different algorithms. It's not about the amount of
> >> > > work it does so much as how efficiently it does it.
> >>
> >> > That's exactly what I was saying. I was talking about speed, not
> >> > efficiency.
> >>
> >> But the efficiency of the algorithm, and the language, affects the speed.
> >> You can't presume "it does more, therefore it takes longer" if the two
> >> programs do things in very different ways.
> >>
> >
> > I was thinking: is it feasible, to "precalculate" the dependency tree?
> > Or, at least "preprocess" all the sane (and insane) dependencies to help
> > portage?
>
>
> I thought that's what the portage cache does, as far as it can.
>
> True, the cache reflects the state of the tree and not the parts of the
> tree a given machine is using, so how big a diff does that give? And
> don't forget overlays - they can slow things down immensely as more
> often than not there's no cache for them unless the user knows to do it
> manually.
>

Well, AFAIK, portage needs to kind of simulate everything going on in an ebuild to get the list of dependencies/blockers... If this can be 'pre-simulated' resulting in a simpler to parse 'database' of dependencies...

Rgds,
--

--bcaec5485b5233cb1904f18327ba--