* Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
@ 2009-02-25 8:33 99% ` Alexis Ballier
0 siblings, 0 replies; 1+ results
From: Alexis Ballier @ 2009-02-25 8:33 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]
On Tue, 24 Feb 2009 19:37:11 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 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.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <1234257125.18160.2016.camel@localhost>
[not found] ` <1234450419.20950.2.camel@localhost>
[not found] ` <20090212160045.GB3642@comet>
[not found] ` <20090212161644.GD3642@comet>
[not found] ` <20090212162103.256b003f@snowcone>
[not found] ` <20090212171055.GA3652@comet>
[not found] ` <20090212172109.778fb268@snowcone>
[not found] ` <20090212173743.GD3652@comet>
[not found] ` <20090212180350.0d9a9df5@snowcone>
[not found] ` <1235037961.13198.779.camel@localhost>
[not found] ` <20090219125124.33eaa66c@snowcone>
[not found] ` <1235077892.13198.1923.camel@localhost>
[not found] ` <20090222171658.278ae167@halo.dirtyepic.sk.ca>
[not found] ` <49A1E1CB.1000806@gentoo.org>
[not found] ` <20090222234800.29d64b8d@snowcone>
2009-02-23 2:15 ` [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Luca Barbato
2009-02-24 7:08 ` Luca Barbato
2009-02-24 14:19 ` Ciaran McCreesh
2009-02-24 16:04 ` Luca Barbato
2009-02-24 16:14 ` Ciaran McCreesh
2009-02-24 17:16 ` Luca Barbato
2009-02-24 18:24 ` Ciaran McCreesh
2009-02-24 19:28 ` Alexis Ballier
2009-02-24 19:37 ` Ciaran McCreesh
2009-02-25 8:33 99% ` Alexis Ballier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox