| 1 |
On Tue, 24 Feb 2009 20:28:43 +0100 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
> On Tue, 24 Feb 2009 18:24:16 +0000 |
| 4 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 5 |
> > On Tue, 24 Feb 2009 18:16:54 +0100 |
| 6 |
> > Luca Barbato <lu_zero@g.o> wrote: |
| 7 |
> > > > You're doubling the number of files that have to be read for an |
| 8 |
> > > > operation that's almost purely i/o bound. On top of that, you're |
| 9 |
> > > > introducing a whole bunch of disk seeks in what's otherwise a |
| 10 |
> > > > nice linear operation. |
| 11 |
> > > |
| 12 |
> > > I see words, not numbers. |
| 13 |
> > |
| 14 |
> > Number: double. That's a '2 times'. |
| 15 |
> |
| 16 |
> That only means you're increasing the constant factor in the |
| 17 |
> complexity of the thing... which may very well be completely |
| 18 |
> negligible unless someone provides real benchmarks. |
| 19 |
|
| 20 |
In the most common case where metadata is valid, around half of the |
| 21 |
time it takes Paludis to work out a resolution set is spent grabbing |
| 22 |
metadata for ebuilds. |
| 23 |
|
| 24 |
> I would be very surprised if that "2 times" factor happens to be true, |
| 25 |
> because finding a string in a file is an order of magnitude simpler |
| 26 |
> than sourcing said file with bash. Moreover this doesn't take into |
| 27 |
> account disk and os cache. |
| 28 |
|
| 29 |
No no no. *Opening* the file is the slow part, not searching. The file |
| 30 |
wouldn't otherwise be opened at all. |
| 31 |
|
| 32 |
-- |
| 33 |
Ciaran McCreesh |
Archives