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 1Lc35m-0002f7-Hg for garchives@archives.gentoo.org; Tue, 24 Feb 2009 19:37:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33729E0515; Tue, 24 Feb 2009 19:37:21 +0000 (UTC) Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by pigeon.gentoo.org (Postfix) with ESMTP id D2734E0569 for ; Tue, 24 Feb 2009 19:37:20 +0000 (UTC) Received: by fxm5 with SMTP id 5so2982161fxm.10 for ; Tue, 24 Feb 2009 11:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=PpHJb2pIgUBp5qD9BsH/836jToUmRd3B2BNI1YmWTVo=; b=pqQmXjkouEBL6yFZwhKTagXpl8wusLJo2yP86owBat1ZiCu28KBL/hQU2YR2tGI746 aBEVbwvxfo/suK0Q706ZKlLj+UnC4EDDN5rMe6V7YuwqdYpKwezCCYzetrDXXwMWDZjG 79HaolMrWTDG92yqpXyHZIhpHQ5biN0Goz4ZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=c2YkXB2A8jEoqjHiOy/jqwlc8Vt2mwQ9Yj18YX7eVJMTLdtv5r4qweQM1qox/1Wfid SWvuGc4I2m+Y7EmoQxltnv8e44HC/yrMZ8JtBZIyUqT1fAB/McoIR4b7FG//geMeMuiE T1G6nJGWwZKo4BwvwTBIdqAw4cxKwNW2Bc4ps= Received: by 10.103.198.20 with SMTP id a20mr2641muq.63.1235504239691; Tue, 24 Feb 2009 11:37:19 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id y7sm19979789ugc.4.2009.02.24.11.37.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 11:37:19 -0800 (PST) Date: Tue, 24 Feb 2009 19:37:11 +0000 From: Ciaran McCreesh 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: <20090224193711.2d99ca4f@snowcone> In-Reply-To: <20090224202843.6c8b89e7@gentoo.org> 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> 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_/eXrywV07+J3Jh_1QqI.54NE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 09cf4d07-7dde-4d8d-8935-f1ba95ab07eb X-Archives-Hash: 8b583ff45af81508bfebfbae18428a7c --Sig_/eXrywV07+J3Jh_1QqI.54NE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. 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. --=20 Ciaran McCreesh --Sig_/eXrywV07+J3Jh_1QqI.54NE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkTGoACgkQ96zL6DUtXhEMhgCg1oVIv4Ylv7/idoHOfbvELXVp GqkAoIN3GOQilKyRmOwBQo1PfvmmiU4m =qN/i -----END PGP SIGNATURE----- --Sig_/eXrywV07+J3Jh_1QqI.54NE--