On Mon, Jul 7, 2014 at 9:39 PM, Duncan <1i5t5.dun...@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
