Hi!
On Sun, Oct 21, 2012 at 08:02:47AM +0000, Duncan wrote:
> Bottom line, an empty @system set really does make a noticeable
> difference in parallel merge handling, speeding up especially --emptytree
> @world rebuilds but also any general update that has a significant number
> of otherwise @system packages and deps, dramatically. I'm happy. =:^)
I think "@system first" and "@system not merge in parallel" rules are safe
to break when you just doing "--emptytree @world" on already updated OS
because it's only rebuild existing packages, and all packages while
compiling will see same set of other packages (including same versions).
But when upgrading multiple packages (including some from original @system
and some from @world) this probably may result in bugs.
As for "--emptytree @world" speedup, can you provide benchmarked values?
I mean, only few packages forced to use only one CPU Core while compiling.
So, merging packages in parallel may save some time mostly for doing
unpack/prepare/configure/install/merge. All of them except configure
actually do a lot of I/O, which most likely lose a lot in speed instead of
gain when done in parallel (especially keeping in mind kernel bug 12309).
So, at a glance time you may win on configure you'll mostly lose on I/O,
and most of time all your CPU Cores will be loaded anyway while compiling,
and doing configure in parallel to compiling unlikely save some time.
This is why I think without actual benchmarking we can't be sure how
faster it became (if it became faster at all, which is questionable).
As for me, I found very effective way to speedup emerge is upgrading from
Core2Duo E6600 to i7-2600K overclocked to 4.6GHz. This speedup compilation
on my system in 6 times (kernel now compiles in just 1 minute). And to
speedup most other (non-compilation) portage operations I use 4GB tmpfs
mount on /var/tmp/portage/.
--
WBR, Alex.
