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 6E94413877A for ; Wed, 9 Jul 2014 09:52:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D42DEE088A; Wed, 9 Jul 2014 09:52:33 +0000 (UTC) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E1888E084E for ; Wed, 9 Jul 2014 09:52:32 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id db12so2278142veb.16 for ; Wed, 09 Jul 2014 02:52:31 -0700 (PDT) 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=Iu4oq35S6Yxf1vZi/CoaSofOlbAj3IyCU5onwz8lb+A=; b=X8PFxSQCvJTPLz0iTV/KDDzmj4xmjRE8dWRFE8T8qeMG42ous7hw0vdcBCU8meuE3P eNhJCfrN0+7Vhu01+fhWVk6kFUPDYourmuEG+Jt+CH62q6LKCiBc6r5ndSWmELE9+OfW Rhkaxs525ugFoT1QU4EBWM5bZlIk1CIYA8LUbzXG3WLRh+M6GzRq/fwB+35jqPn04B+P kou/yl/cxTGGM5Ql8hZc2P18ZSIbYOQxDAkzP8gqZzxhBXV0c08QjCgYbodqbVEhLuhD Hhemvkxkg940pgB/zXVeArvf67MU+33VI+Fw944jg/iiQYPGM6fzt4MUbO6ixJHuNID2 urVw== X-Gm-Message-State: ALoCoQn9HjBvcJSPHxDBfNhCjqxy4ERaWuPfUSRYp6VRR8KgIrTT5WRSw6Vfsd5dXs3GPQFU53V4 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.220.203.134 with SMTP id fi6mr38779068vcb.18.1404899551720; Wed, 09 Jul 2014 02:52:31 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.220.141.207 with HTTP; Wed, 9 Jul 2014 02:52:31 -0700 (PDT) X-Originating-IP: [75.147.143.254] In-Reply-To: References: Date: Wed, 9 Jul 2014 02:52:31 -0700 X-Google-Sender-Auth: upa1asVNa3A5MaZ-rKeYbqSwwDo Message-ID: Subject: Re: [gentoo-dev] Re: Is || ( Atom... ) broken? From: Greg Turner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: d12b84bd-7268-4cb7-be9a-2c54a4033ab5 X-Archives-Hash: 63518254971fd5f291d548905e2fa020 On Mon, Jul 7, 2014 at 9:39 PM, Duncan <1i5t5.duncan@cox.net> wrote: > But from the sound of things, default backtrack=10, multilib, full > @system set and default profile use, on spinning rust, is getting all but > intolerable now. =:^( Actually a mix of RAID0 and RAID1 over fast, new-ish SSDs -- anyhow I doubt it would matter on spinning rust. When I sync, I run egencache on everything and then emerge --metadata, so by the time I run emerge -u*, it's against a warm cache; the disk light basically stays dark the whole time. But, I have overlays with forced eclass overrides, and over 2000 packages installed. Furthermore, after a sync, I'm often waiting for emerge to fail, not to succeed. For example, say I've multilibutized something upstream hasn't, and upstream has version-bumped their non-multilibutized ebuild (but not multilibutized it); and say I have packages installed requiring multilib in the same slot -- that's a scenario I frequently find myself in. Worse, I will usually provide --complete-graph to portage (because otherwise, portage can fail to show me the clues I need to detect precisely this problem). Basically, you could say my use case is the perfect storm of ways to make emerge slow. I probably wouldn't be kept waiting for those 30 minutes unless I'd waited a week or two, and let gx86 provide newer versions of several of my ebuilds. I'm pretty sure this triggers massive amounts of backtracking. By the way, I've profiled depsolving on my system. Portage spends a /majority/ of it's depsolving time solving regexes on behalf of portage.dep.Atom. I have an untested theory that, without fixing any algorithmic stuff, we could reap a meaningful O(1) gain implementing, say, a CustomAtom (inherited by Atom) in cpython that does most of its string parsing in hand-coded C. -gmt