Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 24 Feb 2009 18:24:16 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 24 Feb 2009 18:16:54 +0100
> > Luca Barbato <lu_zero@gentoo.org> 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.

> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]