From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9jpq-0007g6-Gl for garchives@archives.gentoo.org; Thu, 28 May 2009 17:56:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 54C80E05CB; Thu, 28 May 2009 17:56:08 +0000 (UTC) Received: from smarthost03.mail.zen.net.uk (smarthost03.mail.zen.net.uk [212.23.3.142]) by pigeon.gentoo.org (Postfix) with ESMTP id 1E83AE05CB for ; Thu, 28 May 2009 17:56:08 +0000 (UTC) Received: from [62.3.120.141] (helo=NeddySeagoon) by smarthost03.mail.zen.net.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1M9jpn-000228-GX for gentoo-dev@lists.gentoo.org; Thu, 28 May 2009 17:56:07 +0000 Date: Thu, 28 May 2009 18:56:00 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28 To: gentoo-dev@lists.gentoo.org In-Reply-To: <1243489596.10450.24.camel@localhost> (from dev-zero@gentoo.org on Thu May 28 06:46:36 2009) X-Mailer: Balsa 2.3.28 Message-Id: <1243533366.3439.0@NeddySeagoon> 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: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Originating-Smarthost03-IP: [62.3.120.141] X-Archives-Salt: e8b3f044-84d7-498c-b668-a3af5b0c2c55 X-Archives-Hash: 9d83e6c79b139d13e9df74bdbfdeb1a7 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.05.28 06:46, Tiziano M=FCller wrote: [snip] > I did some analysis on that. The result is that the the performance > penalty of not having the EAPI not in the filename depends on various > factors. But it is for sure that there is a performance penalty. It needs to be quantified in the GLEP. Nobody wants to trawl this list looking for it. >=20 [snip the process - its an implementaion detail] > So, one of the main differences is: "reading one cache file" (if > running > unstable you can asssume you support the highest version, thus=20 > reading > only one cache file) vs. "reading all cache files". >=20 > I did some performance measurements based on that. I have 1507 > installed > packages with 5541 different versions/revisions. >=20 > Reading from hot cache: > 1507 files: ~50ms > 5541 files: ~170ms >=20 > Reading from cold cache: > 1507 files: ~2.8s > 5541 files: ~6s As I understand this, it may add six seconds to an emerge world while=20 the dep tree is calculated. Lets say it takes an hour to do emerge=20 world, the time has increased from 3600 seconds to 3606 seconds or a=20 trivial 0.1666667% We are clearly concentrating our efforts in wrong area, trying to=20 reduce the six seconds. >=20 > I made a lot of assumptions here (neglecting seek between ebuild-dir > and > metadata-dir, other processes using the drive, 80 ebuilds from > overlays > where the ebuild would have to be read, etc.). But estimating from=20 > the > numbers above I'd say that a "emerge -uD world"/"paludis -i world" > will > be at least twice as slow, which I think is not acceptable. You mean 0.3% (or less) of the emerge world time? >=20 > And I also don't understand your point of stating it's "bad design".=20 > I mean: when coding you should "not optimize prematurely", but with > eapi-in-ebuild it is against the other principle of "not pessimize > prematurely" (Sutter/Alexandrescu: C++ Coding Standards). Coding Standards (whatever language) are not relevant. My point comes=20 from Systems Design, before your write the Systems Requirement Document=20 and the System Implementation Plan and even the Top Level Design=20 document. ... thats a long time before you write any code.=20 I am against *all* and any metadata in the filename. Today, GLEP 55=20 proposes the add the EAIP, tomorrow, there will be something else, the day after another thing ... and all because allowing EAPI set the=20 precedent. You also make the error of assuming that with eapi-in-ebuild the=20 currently suggested approaches to extracting the EAPI from the ebuild=20 are the best and remain unchanged. Thats unlikely, as not a lot of work=20 has been done it yet. >=20 >=20 > --=20 > Tiziano M=FCller > Gentoo Linux Developer, Council Member > Areas of responsibility: > Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor > E-Mail : dev-zero@gentoo.org > GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 >=20 - --=20 Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoe0DYACgkQTE4/y7nJvasUGwCglincQpLkCw7C09Z4zNTY1PL1 s1gAoK7NTbOl5tdGOngtufe81ocwNRXp =3DRu66 -----END PGP SIGNATURE-----