| 1 |
On Tue, 24 Feb 2009 19:37:11 +0000 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Tue, 24 Feb 2009 20:28:43 +0100 |
| 5 |
> Alexis Ballier <aballier@g.o> wrote: |
| 6 |
> > On Tue, 24 Feb 2009 18:24:16 +0000 |
| 7 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 8 |
> > > On Tue, 24 Feb 2009 18:16:54 +0100 |
| 9 |
> > > Luca Barbato <lu_zero@g.o> wrote: |
| 10 |
> > > > > You're doubling the number of files that have to be read for |
| 11 |
> > > > > an operation that's almost purely i/o bound. On top of that, |
| 12 |
> > > > > you're introducing a whole bunch of disk seeks in what's |
| 13 |
> > > > > otherwise a nice linear operation. |
| 14 |
> > > > |
| 15 |
> > > > I see words, not numbers. |
| 16 |
> > > |
| 17 |
> > > Number: double. That's a '2 times'. |
| 18 |
> > |
| 19 |
> > That only means you're increasing the constant factor in the |
| 20 |
> > complexity of the thing... which may very well be completely |
| 21 |
> > negligible unless someone provides real benchmarks. |
| 22 |
> |
| 23 |
> In the most common case where metadata is valid, around half of the |
| 24 |
> time it takes Paludis to work out a resolution set is spent grabbing |
| 25 |
> metadata for ebuilds. |
| 26 |
|
| 27 |
That sounds like an implementation detail that you could solve by using |
| 28 |
something else than a flat file database for metadata if open()/read() |
| 29 |
calls are the slow part. |
| 30 |
|
| 31 |
> > I would be very surprised if that "2 times" factor happens to be |
| 32 |
> > true, because finding a string in a file is an order of magnitude |
| 33 |
> > simpler than sourcing said file with bash. Moreover this doesn't |
| 34 |
> > take into account disk and os cache. |
| 35 |
> |
| 36 |
> No no no. *Opening* the file is the slow part, not searching. The file |
| 37 |
> wouldn't otherwise be opened at all. |
| 38 |
|
| 39 |
Thus the only drawback is when you open a file, see there that you can't |
| 40 |
handle the eapi, then close it and open an older one. So you're doing |
| 41 |
useless things only in that case which in practice will have a ratio |
| 42 |
far lower than 2. Moreover Luca's benchs show that searching for file |
| 43 |
names is a negligible factor faster than grepping them while you're |
| 44 |
just stating that it isn't. |
| 45 |
|
| 46 |
Alexis. |
Archives