1 |
Am Mittwoch, den 27.05.2009, 22:43 +0100 schrieb Roy Bamford: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On 2009.05.27 21:06, Ciaran McCreesh wrote: |
6 |
> > -----BEGIN PGP SIGNED MESSAGE----- |
7 |
> > Hash: SHA1 |
8 |
> > |
9 |
> > On Wed, 27 May 2009 20:55:33 +0100 |
10 |
> > Roy Bamford <neddyseagoon@g.o> wrote: |
11 |
> > > That means the EAPI needs to be extracted before the ebuild is |
12 |
> > > sourced, which from the figures bandied about on the list may take |
13 |
> > > marginaly longer but its a price worth paying for a sound system |
14 |
> > > design. Gentoo should not repeat the VHS vs Betamax war. For those |
15 |
> > > who do not remember, VHS was the better marketed but inferior |
16 |
> > > technical solution that won the standards war for domestic Video |
17 |
> > > recorders. |
18 |
> > > |
19 |
> > > The aims of GLEP 55 are good but the proposed implementaion is bad |
20 |
> > > practice, so GLEP 55 should be rejected in its present form. |
21 |
> > |
22 |
> > You have not made a single technical argument in your entire message. |
23 |
> > Please don't add yet more noise to the discussion. |
24 |
> > |
25 |
> > - -- |
26 |
> > Ciaran McCreesh |
27 |
> > -----BEGIN PGP SIGNATURE----- |
28 |
> > Version: GnuPG v2.0.9 (GNU/Linux) |
29 |
> > |
30 |
> > iEYEARECAAYFAkodnVkACgkQ96zL6DUtXhGerACcC2khWKdGKCaMTi7zE/jYyUUw |
31 |
> > bU8AnA5Gg6bDz/JiDIwMB98R5t9dQNLg |
32 |
> > =bfse |
33 |
> > -----END PGP SIGNATURE----- |
34 |
> > |
35 |
> Ciaran, |
36 |
> |
37 |
> You chose to ignore "Adding metadata to the filename is not required |
38 |
> and is bad system design practice." |
39 |
> |
40 |
> I assume you agree with that as you chose to snip it, not to refute it |
41 |
> with a technical argument? |
42 |
> |
43 |
> |
44 |
> |
45 |
> GLEP 55 is a poor piece of technical writing. The title |
46 |
> <quote> |
47 |
> Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) |
48 |
> </quote> |
49 |
> should be an area to be impvoved not a possible solution that has not |
50 |
> even been discussed (in the document) yet. |
51 |
> |
52 |
> The abstract tells readers more about a proposed solution. |
53 |
> <quote> |
54 |
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds |
55 |
> (for example, foo-1.2.3.ebuild-1). |
56 |
> </quote> |
57 |
> and readers still don't know the problem that it tries to address. |
58 |
> |
59 |
> The statement of the problem is not entirely correct either ... |
60 |
> <quote>The current way of specifying the EAPI in ebuilds is flawed. |
61 |
> In order to get the EAPI the package manager needs to source the |
62 |
> ebuild, |
63 |
> </quote> |
64 |
> Nope, in order to get the EAPI, the PM needs to parse the ebuild, it |
65 |
> need not source it. Thats a statement of the current design. |
66 |
> |
67 |
> <quote> |
68 |
> which itself needs the EAPI in the first place. |
69 |
> </quote> |
70 |
> Well, thats what current designs do, its a design than can be changed. |
71 |
> |
72 |
> <quote>Otherwise it imposes a serious limitation, namely every ebuild, |
73 |
> using any of the future EAPIs, will have to be source'able by old |
74 |
> package managers |
75 |
> </quote> |
76 |
> That is true, unless the .ebuild extension is changed so we get a clean |
77 |
> break with the past. It does not mean the EAPI needs to be a part of |
78 |
> the file name. |
79 |
> |
80 |
> The GLEP discusses this and and dismisses it for no sound technical |
81 |
> reasons. |
82 |
> |
83 |
> Until we get to the Abstract solution, the GLEP reads like a sales |
84 |
> brouchre, which is what reminded me of VHS vs Betamax. |
85 |
> <quote> |
86 |
> A solution to this problem has to lift those limitations and the only |
87 |
> way to do it is to make the EAPI of an ebuild available to the package |
88 |
> managers in a way that doesn't require them to source the ebuild. |
89 |
> Another important requirement is for the solution to be backward |
90 |
> compatible, which has the pleasant side-effect of making the solution |
91 |
> applicable in the Gentoo tree right away. A solution to this problem |
92 |
> has to lift those limitations and the only |
93 |
> way to do it is to make the EAPI of an ebuild available to the package |
94 |
> managers in a way that doesn't require them to source the ebuild. |
95 |
> </quote> |
96 |
> Thats all true or highly desireable. |
97 |
> |
98 |
> The |
99 |
> <quote> |
100 |
> Hurts performance: yes |
101 |
> </quote> |
102 |
> needs to be quantifed and included in the GLEP, so that readers can |
103 |
> make an impartial objective assessment of the alternatives on offer and |
104 |
> hopefully support the best technical solution. That need not be the |
105 |
> fastest. |
106 |
|
107 |
I did some analysis on that. The result is that the the performance |
108 |
penalty of not having the EAPI not in the filename depends on various |
109 |
factors. But it is for sure that there is a performance penalty. |
110 |
|
111 |
And here is why (I'm only looking at the non-degenerated case with valid |
112 |
metadata, ignoring overlays which some consider a corner case (I don't |
113 |
understand that argument, but that's another thing)): |
114 |
|
115 |
When the package manager looks at a package, it first reads the |
116 |
package's ebuild directory and gets the mtimes. It does the same for the |
117 |
cache entries and validates the caches (there is more stuff in here, |
118 |
like checking eclasses and so on). |
119 |
Then the following happens based on the "solution" we choose: |
120 |
eapi-in-filename: the package manager starts from the highest version |
121 |
with a supported eapi (the others are inexistant with the used glob). |
122 |
For that ebuild it reads the cache entry and decides whether or not it |
123 |
can be used. If not, it proceeds to the next version, if yes, it's done. |
124 |
eapi-in-ebuild: the package manager reads all cache entries and sorts |
125 |
out those with an EAPI it doesn't support. The rest gets ordered and the |
126 |
same procedure as above applies. |
127 |
|
128 |
So, one of the main differences is: "reading one cache file" (if running |
129 |
unstable you can asssume you support the highest version, thus reading |
130 |
only one cache file) vs. "reading all cache files". |
131 |
|
132 |
I did some performance measurements based on that. I have 1507 installed |
133 |
packages with 5541 different versions/revisions. |
134 |
|
135 |
Reading from hot cache: |
136 |
1507 files: ~50ms |
137 |
5541 files: ~170ms |
138 |
|
139 |
Reading from cold cache: |
140 |
1507 files: ~2.8s |
141 |
5541 files: ~6s |
142 |
|
143 |
I made a lot of assumptions here (neglecting seek between ebuild-dir and |
144 |
metadata-dir, other processes using the drive, 80 ebuilds from overlays |
145 |
where the ebuild would have to be read, etc.). But estimating from the |
146 |
numbers above I'd say that a "emerge -uD world"/"paludis -i world" will |
147 |
be at least twice as slow, which I think is not acceptable. |
148 |
|
149 |
And I also don't understand your point of stating it's "bad design". I |
150 |
mean: when coding you should "not optimize prematurely", but with |
151 |
eapi-in-ebuild it is against the other principle of "not pessimize |
152 |
prematurely" (Sutter/Alexandrescu: C++ Coding Standards). |
153 |
|
154 |
|
155 |
|
156 |
-- |
157 |
Tiziano Müller |
158 |
Gentoo Linux Developer, Council Member |
159 |
Areas of responsibility: |
160 |
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor |
161 |
E-Mail : dev-zero@g.o |
162 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |