1 |
Ciaran McCreesh wrote: |
2 |
> On Wed, 25 Feb 2009 09:33:44 +0100 |
3 |
> Alexis Ballier <aballier@g.o> wrote: |
4 |
>> That sounds like an implementation detail that you could solve by |
5 |
>> using something else than a flat file database for metadata if |
6 |
>> open()/read() calls are the slow part. |
7 |
> |
8 |
> Metadata's shipped with the tree. It's a PMS detail. |
9 |
> |
10 |
> If we didn't care about package manager performance, we wouldn't be |
11 |
> shipping metadata with the tree at all... |
12 |
> |
13 |
>>>> I would be very surprised if that "2 times" factor happens to be |
14 |
>>>> true, because finding a string in a file is an order of magnitude |
15 |
>>>> simpler than sourcing said file with bash. Moreover this doesn't |
16 |
>>>> take into account disk and os cache. |
17 |
>>> No no no. *Opening* the file is the slow part, not searching. The |
18 |
>>> file wouldn't otherwise be opened at all. |
19 |
>> Thus the only drawback is when you open a file, see there that you |
20 |
>> can't handle the eapi, then close it and open an older one. |
21 |
> |
22 |
> Uh. No. The drawback is that you're opening around ten thousand files |
23 |
> that would otherwise not be opened. That's a huge cost. |
24 |
> |
25 |
|
26 |
Huge cost... |
27 |
|
28 |
emerge -uDp world (cold os cache) |
29 |
|
30 |
real 1m10.353s |
31 |
user 0m17.077s |
32 |
sys 0m0.440s |
33 |
|
34 |
with eapitool getting the eapi before sourcing. |
35 |
|
36 |
real 1m10.636s |
37 |
user 0m16.941s |
38 |
sys 0m0.368s |
39 |
|
40 |
cold cache, no metadata available |
41 |
|
42 |
real 6m23.106s |
43 |
user 3m32.141s |
44 |
sys 1m50.855s |
45 |
|
46 |
with eapitool |
47 |
|
48 |
real 6m26.564s |
49 |
user 3m31.853s |
50 |
sys 1m50.511s |
51 |
|
52 |
|
53 |
I'd rather see more people backing their ideas with numbers... |
54 |
|
55 |
lu |
56 |
|
57 |
-- |
58 |
|
59 |
Luca Barbato |
60 |
Gentoo Council Member |
61 |
Gentoo/linux Gentoo/PPC |
62 |
http://dev.gentoo.org/~lu_zero |