On Tue, 24 Feb 2009 19:37:11 +0000 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Tue, 24 Feb 2009 20:28:43 +0100 > Alexis Ballier <aball...@gentoo.org> wrote: > > On Tue, 24 Feb 2009 18:24:16 +0000 > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Tue, 24 Feb 2009 18:16:54 +0100 > > > Luca Barbato <lu_z...@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.
signature.asc
Description: PGP signature
