| 1 |
On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
[...] |
| 4 |
>> The first read will cause the file to be cached for subsequent reads |
| 5 |
>> anyway, so the performance hit boils down to an additional read() call |
| 6 |
>> (which will probably be buffered by your file I/O library anyway, so |
| 7 |
>> it's unlikely to even result in a context switch). And even without, |
| 8 |
>> it is well worth the lack of fugliness in the ebuild name. |
| 9 |
> |
| 10 |
> No, it results in a new open() on a file that's elsewhere on disk, which |
| 11 |
> results in two new seeks. You get about fifty seeks per second. |
| 12 |
|
| 13 |
Well, most file systems have a local structure for this data (=> block |
| 14 |
group), so it's not going to be a seek that's very far. Secondly, how |
| 15 |
many ebuilds do you need to read directly to get this data in a |
| 16 |
typical case? Isn't this what the metadata cache is for? |
| 17 |
|
| 18 |
>> > - it heavily restricts future syntax and meaning of EAPIs |
| 19 |
>> |
| 20 |
>> Not by much. It's just a header. |
| 21 |
> |
| 22 |
> <!-- EAPI="3" --> |
| 23 |
|
| 24 |
Do we want to keep the spec so wide open that we support any format |
| 25 |
under the Sun that we fancy? Seems like overgeneralizing to me. |
| 26 |
|
| 27 |
Regards, |
| 28 |
-- |
| 29 |
Arun Raghavan |
| 30 |
(http://nemesis.accosted.net) |
| 31 |
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 |
| 32 |
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com |
| 33 |
-- |
| 34 |
gentoo-dev@l.g.o mailing list |
Archives