From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LcFDG-0002JE-Lh for garchives@archives.gentoo.org; Wed, 25 Feb 2009 08:33:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3933E0377; Wed, 25 Feb 2009 08:33:52 +0000 (UTC) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 26E41E0377 for ; Wed, 25 Feb 2009 08:33:50 +0000 (UTC) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 38E01940183 for ; Wed, 25 Feb 2009 09:33:47 +0100 (CET) Received: from localhost (toz.strangled.net [82.232.126.136]) by smtp1-g21.free.fr (Postfix) with ESMTP id 257A2940031 for ; Wed, 25 Feb 2009 09:33:45 +0100 (CET) Date: Wed, 25 Feb 2009 09:33:44 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090225093344.1858b384@gentoo.org> In-Reply-To: <20090224193711.2d99ca4f@snowcone> References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <49A39CE7.4010201@gentoo.org> <20090224141912.0a666a17@snowcone> <49A41A8C.1060002@gentoo.org> <20090224161449.07bc580a@snowcone> <49A42B86.9010903@gentoo.org> <20090224182416.3db4f60f@snowcone> <20090224202843.6c8b89e7@gentoo.org> <20090224193711.2d99ca4f@snowcone> Organization: Gentoo X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/rG7/OvZ54v_0pBO1zLFfzSH"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: ec4e9a78-2b79-4547-8f50-f1052ca9a1dd X-Archives-Hash: 34ab826430d18a84c3bbdea39d5e47cc --Sig_/rG7/OvZ54v_0pBO1zLFfzSH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 19:37:11 +0000 Ciaran McCreesh wrote: > On Tue, 24 Feb 2009 20:28:43 +0100 > Alexis Ballier wrote: > > On Tue, 24 Feb 2009 18:24:16 +0000 > > Ciaran McCreesh wrote: > > > On Tue, 24 Feb 2009 18:16:54 +0100 > > > Luca Barbato 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. > > > >=20 > > > > I see words, not numbers. > > >=20 > > > Number: double. That's a '2 times'. > >=20 > > 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. >=20 > 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. >=20 > 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. --Sig_/rG7/OvZ54v_0pBO1zLFfzSH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmlAmgACgkQvFcC4BYPU0opDgCguvKZ/j3LFTXogZyHokvnR+rY OZ4AnRrfDP/02Xz2fqtb4G901c+1CsxM =u/aH -----END PGP SIGNATURE----- --Sig_/rG7/OvZ54v_0pBO1zLFfzSH--