1 |
Brian Harring wrote: |
2 |
|
3 |
> On Thu, Mar 20, 2008 at 06:51:13AM +0000, Steve Long wrote: |
4 |
>> I don't have figures, but my understanding is that one of the major |
5 |
>> factors in pkgcore's speed (which *is* impressive, even if the UI isn't |
6 |
>> quite there yet) is that it doesn't reload bash for every phase. (The |
7 |
>> whole ebuild "daemon" or ebd thing.) |
8 |
> |
9 |
> From a speed standpoint, EBD is only relevant if we're talking about |
10 |
> metadata regeneration- |
11 |
> |
12 |
http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt |
13 |
> |
14 |
Ah OK; thanks, very interesting post. |
15 |
|
16 |
> Generally speaking, if you're sourcing to get metadata (regardless of |
17 |
> the underlying format), you're already screwed- cache exists for a |
18 |
> reason and is massively faster to rely on. Pkgcore's speed comes |
19 |
> about from careful design + a massive amount of JIT, EBD is faster |
20 |
> then the alternatives but that's *only* relevant for metadata |
21 |
> regeneration. |
22 |
> |
23 |
Would the metadata regen be quicker if the relevant file were in python |
24 |
rather than bash? |
25 |
|
26 |
> Finally, bear in mind we're talking about build phase here- even if |
27 |
> the pkg is just a straight unpack/copy, the bottleneck there isn't |
28 |
> going to be the bash bits for setting up the env, it's going to be the |
29 |
> unpack, copy, multiple QA checks that do repeated find's across ${D}, |
30 |
> multiple file invocations for same file, etc. Seriously- profile a |
31 |
> merge sometime, even on non-compilations the large time slices are |
32 |
> never bash. |
33 |
|
34 |
Understood; thanks for discussing. |
35 |
|
36 |
I was under the impression that implicit in the design of portage/pkgcore, |
37 |
was that build scripts wouldn't necessarily be in bash, and that ebuild was |
38 |
simply the bash format. Other formats in scripting languages seemed a |
39 |
no-brainer; sorry if it was off-base. |
40 |
|
41 |
|
42 |
-- |
43 |
gentoo-dev@l.g.o mailing list |