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 848CE1392EF for ; Wed, 9 Jul 2014 12:35:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E55A5E085E; Wed, 9 Jul 2014 12:34:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EA489E084D for ; Wed, 9 Jul 2014 12:34:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E383134001E for ; Wed, 9 Jul 2014 12:34:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5.5 tests=[AWL=-0.832, RP_MATCHES_RCVD=-0.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h9Zbtpo8uu5 for ; Wed, 9 Jul 2014 12:34:52 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 3130B33FF14 for ; Wed, 9 Jul 2014 12:34:51 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X4r5F-00042K-FG for gentoo-dev@gentoo.org; Wed, 09 Jul 2014 14:34:49 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jul 2014 14:34:49 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jul 2014 14:34:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Is || ( Atom... ) broken? Date: Wed, 9 Jul 2014 12:34:37 +0000 (UTC) Message-ID: References: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: bd72a14d-76db-4652-ae0a-ec032f611590 X-Archives-Hash: 20b5366eda0427238ae092b7f08d222c Greg Turner posted on Wed, 09 Jul 2014 02:52:31 -0700 as excerpted: > 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. > > Worse, I will usually provide --complete-graph to portage (because > otherwise, portage can fail to show me the clues I need[.] Basically, > you could say my use case is the perfect storm of ways to make emerge > slow. OK; makes more sense, now. > 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. Have you /tried/ backtrack=0? Someone suggested it and I was a bit skeptical, but one day after waiting for the 10 backtracks to complete, only to see portage tell me it needed my help to solve the problem anyway, I decided to try it. It's likely I'm doing a bit more work myself now, but not /that/ much more, and at least it gets done faster, giving me enough information to actually do something about it sooner. If as you say you're often waiting for emerge to fail, then backtrack=0 may well shave significant time off that failure and let you deal with it sooner, as it seems to have done for me. > 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. Sounds reasonable, but that's well out of my league to code up, so... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman