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.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. > > 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
