| 1 |
On Tue, 10 Jun 2008 16:11:49 +0200 |
| 2 |
Rémi Cardona <remi@g.o> wrote: |
| 3 |
> Ciaran McCreesh a écrit : |
| 4 |
> > The package manager does not currently source the whole thing with |
| 5 |
> > bash to get the EAPI, nor does it open the ebuild file at all for |
| 6 |
> > metadata. You're talking doubling the number of file operations |
| 7 |
> > here, and going from extremely good filesystem locality (which |
| 8 |
> > means very few seeks) to jumping backwards and forwards all over |
| 9 |
> > the place. |
| 10 |
> |
| 11 |
> Yeah, grepping through the ebuild is just bound to get a massive |
| 12 |
> performance hit, I don't have numbers but that just looks obvious. |
| 13 |
|
| 14 |
No no. Doing the seek to open a file in a different directory and then |
| 15 |
seeking back to your original directory over and over when otherwise |
| 16 |
you'd be doing nice linear opens on adjacent inodes in a single |
| 17 |
directory is where the performance hit is. |
| 18 |
|
| 19 |
Paludis is pretty much seek bound in a lot of cases. |
| 20 |
|
| 21 |
> Ciaran, what other pitfalls do you see for using one EAPI file per |
| 22 |
> package (except for the broken compatibility, I know it's a big one) ? |
| 23 |
|
| 24 |
It's moving the relevant information further and further away from |
| 25 |
where it's supposed to be. It doubles the number of files a developer |
| 26 |
has to check in order to do simple ebuild maintenance. |
| 27 |
|
| 28 |
-- |
| 29 |
Ciaran McCreesh |
Archives