On Tue, 24 Feb 2009 19:37:11 +0000
Ciaran McCreesh <ciaran.mccreesh@...> wrote:

> On Tue, 24 Feb 2009 20:28:43 +0100
> Alexis Ballier <aballier@g.o> wrote:
> > On Tue, 24 Feb 2009 18:24:16 +0000
> > Ciaran McCreesh <ciaran.mccreesh@...> wrote:
> > > On Tue, 24 Feb 2009 18:16:54 +0100
> > > Luca Barbato <lu_zero@g.o> wrote:
> > > > > You're doubling the number of files that have to be read for
> > > > > an operation that's almost purely i/o bound. On top of that,
> > > > > you're introducing a whole bunch of disk seeks in what's
> > > > > otherwise a nice linear operation.
> > > > 
> > > > I see words, not numbers.
> > > 
> > > Number: double. That's a '2 times'.
> > 
> > That only means you're increasing the constant factor in the
> > complexity of the thing... which may very well be completely
> > negligible unless someone provides real benchmarks.
> 
> In the most common case where metadata is valid, around half of the
> time it takes Paludis to work out a resolution set is spent grabbing
> metadata for ebuilds.

That sounds like an implementation detail that you could solve by using
something else than a flat file database for metadata if open()/read()
calls are the slow part.

> > I would be very surprised if that "2 times" factor happens to be
> > true, because finding a string in a file is an order of magnitude
> > simpler than sourcing said file with bash. Moreover this doesn't
> > take into account disk and os cache.
> 
> No no no. *Opening* the file is the slow part, not searching. The file
> wouldn't otherwise be opened at all.

Thus the only drawback is when you open a file, see there that you can't
handle the eapi, then close it and open an older one. So you're doing
useless things only in that case which in practice will have a ratio
far lower than 2. Moreover Luca's benchs show that searching for file
names is a negligible factor faster than grepping them while you're
just stating that it isn't.

Alexis.