[gentoo-dev] Re: Re: Re: RFC: New build types

[Steve Long <slong@rathaus.eclipse.co.uk>]

Brian Harring wrote:

> On Thu, Mar 20, 2008 at 06:51:13AM +0000, Steve Long wrote:
>> I don't have figures, but my understanding is that one of the major
>> factors in pkgcore's speed (which *is* impressive, even if the UI isn't
>> quite there yet) is that it doesn't reload bash for every phase. (The
>> whole ebuild "daemon" or ebd thing.)
> 
> From a speed standpoint, EBD is only relevant if we're talking about
> metadata regeneration-
>
http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt
>
Ah OK; thanks, very interesting post.
 
> Generally speaking, if you're sourcing to get metadata (regardless of
> the underlying format), you're already screwed- cache exists for a
> reason and is massively faster to rely on.  Pkgcore's speed comes
> about from careful design + a massive amount of JIT, EBD is faster
> then the alternatives but that's *only* relevant for metadata
> regeneration.
>
Would the metadata regen be quicker if the relevant file were in python
rather than bash?

> Finally, bear in mind we're talking about build phase here- even if
> the pkg is just a straight unpack/copy, the bottleneck there isn't
> going to be the bash bits for setting up the env, it's going to be the
> unpack, copy, multiple QA checks that do repeated find's across ${D},
> multiple file invocations for same file, etc.  Seriously- profile a
> merge sometime, even on non-compilations the large time slices are
> never bash.

Understood; thanks for discussing.

I was under the impression that implicit in the design of portage/pkgcore,
was that build scripts wouldn't necessarily be in bash, and that ebuild was
simply the bash format. Other formats in scripting languages seemed a
no-brainer; sorry if it was off-base.


-- 
gentoo-dev@lists.gentoo.org mailing list