1 |
On Tue, 24 Feb 2009 17:04:28 +0100 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
> Ciaran McCreesh wrote: |
4 |
> > On Tue, 24 Feb 2009 08:08:23 +0100 |
5 |
> > Uh, your benchmarks are nonsense. |
6 |
> |
7 |
> Provide your nonsensical ones. |
8 |
|
9 |
You're doubling the number of files that have to be read for an |
10 |
operation that's almost purely i/o bound. On top of that, you're |
11 |
introducing a whole bunch of disk seeks in what's otherwise a nice |
12 |
linear operation. |
13 |
|
14 |
> > That is not how metadata checks work. |
15 |
> |
16 |
> Explain how they work, regen works that way... |
17 |
|
18 |
If metadata is valid, ebuilds aren't opened at all. An optimal |
19 |
implementation can slurp up the entire directory in one go and then |
20 |
start pulling out cache entries as it needs them, not having to go back |
21 |
to the ebuild directory or read its contents at all. Then it can open |
22 |
and read cache files in a carefully selected order to avoid having to |
23 |
do any more opens than necessary. |
24 |
|
25 |
> > By parsing the ebuilds you're talking doubling the number of file |
26 |
> > reads required to get the job done, and massively increasing the |
27 |
> > number of seeks required. |
28 |
> |
29 |
> Apparently it doesn't impact anything. |
30 |
|
31 |
Please show the patch you created (for Paludis, since Portage doesn't |
32 |
yet do a lot of the optimisations it could here) that demonstrates this. |
33 |
|
34 |
> > But that isn't even the main issue. The main issue is that even if |
35 |
> > you retroactively pretend that all ebuilds are in a format they're |
36 |
> > not, and ignore the breakage, and then wait for a year for package |
37 |
> > managers to try to parse your new format, you *still* can't change |
38 |
> > name or versioning rules. |
39 |
> |
40 |
> why? when portage would breanch if I put an ebuild with a wacky |
41 |
> version AND there is a valid cache for that telling its eapi 99 ? |
42 |
|
43 |
Because it has to parse that version. Also, the package manager can't |
44 |
tell whether or not a cache entry is valid if it doesn't recognise the |
45 |
EAPI in the cache entry. |
46 |
|
47 |
> > Again, these are all things that have been discussed at length |
48 |
> > previously. Please either come up with a legitimate technical |
49 |
> > objection, or admit that you've seen the light. |
50 |
> |
51 |
> the glep doesn't show any of those nor reference to it, as I said |
52 |
> before, do your homework and probably more people will be happier |
53 |
> with your proposals. |
54 |
|
55 |
Why should it? The C++ standard doesn't explain why you should use it |
56 |
instead of Java... |
57 |
|
58 |
-- |
59 |
Ciaran McCreesh |