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 1LcMSE-0002YJ-0b for garchives@archives.gentoo.org; Wed, 25 Feb 2009 16:17:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EA34DE0727; Wed, 25 Feb 2009 16:17:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C90C3E0727 for ; Wed, 25 Feb 2009 16:17:28 +0000 (UTC) Received: from [192.168.0.9] (unknown [151.57.3.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E87D16505B for ; Wed, 25 Feb 2009 16:17:27 +0000 (UTC) Message-ID: <49A56F19.3010201@gentoo.org> Date: Wed, 25 Feb 2009 17:17:29 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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 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) 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> <20090225093344.1858b384@gentoo.org> <20090225153023.4540ad7c@snowcone> In-Reply-To: <20090225153023.4540ad7c@snowcone> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 0a314b67-5d91-467c-828d-ebebe4b42388 X-Archives-Hash: 02ac016f6ca711694ab7c1da0ec2605a Ciaran McCreesh wrote: > On Wed, 25 Feb 2009 09:33:44 +0100 > Alexis Ballier wrote: >> 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. > > Metadata's shipped with the tree. It's a PMS detail. > > If we didn't care about package manager performance, we wouldn't be > shipping metadata with the tree at all... > >>>> 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. > > Uh. No. The drawback is that you're opening around ten thousand files > that would otherwise not be opened. That's a huge cost. > Huge cost... emerge -uDp world (cold os cache) real 1m10.353s user 0m17.077s sys 0m0.440s with eapitool getting the eapi before sourcing. real 1m10.636s user 0m16.941s sys 0m0.368s cold cache, no metadata available real 6m23.106s user 3m32.141s sys 1m50.855s with eapitool real 6m26.564s user 3m31.853s sys 1m50.511s I'd rather see more people backing their ideas with numbers... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero