On Monday, 18 September
2023 14:48:46 BST Alan McKinnon wrote:
> On Mon, Sep 18, 2023 at 3:44 PM Peter Humphrey <peter@prh.myzen.co.uk>
>
> wrote:
> > It may be less complex than you think, Jack. I
envisage a package being
> > marked
> > as solitary, and when portage reaches that
package, it waits until all
> > current
> > jobs have finished, then it starts the solitary
package with the
> > environment
> > specified for it, and it doesn't start the next
one until that one has
> > finished.
> > The dependency calculation shouldn't need to be
changed.
> >
> > It seems simple the way I see it.
>
> How does that improve emerge performance overall?
By allocating all the system resources to huge packages
while not flooding the
system with lesser ones. For example, I can set -j20 for
webkit-gtk today
without overflowing the 64GB RAM, and still have 4 CPU
threads available to
other tasks. The change I've proposed should make the whole
operation more
efficient overall and take less time.
As things stand today, I have to make do with -j12 or so,
wasting time and
resources. I have load-average set at 32, so if I were to
set -j20 generally
I'd run out of RAM in no time. I've had many instances of
packages failing to
compile in a large update, but going just fine on their own;
and I've had
mysterious operational errors resulting, I suspect, from
otherwise undetected
miscompilation.
Previous threads have more detail of what I've tried
already.
I did read all those but no matter how you move things
around you still have only X resources available all the
time.
Whether you just let emerge do it's thing or try get it
to do big packages on their own, everything is still going
to use the same number of cpu cycles overall and you will
save nothing.