Re: [gentoo-dev] Re: Is || ( Atom... ) broken?

[Greg Turner]

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