From: Roy Bamford <neddyseagoon@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28
Date: Thu, 28 May 2009 18:56:00 +0100 [thread overview]
Message-ID: <1243533366.3439.0@NeddySeagoon> (raw)
In-Reply-To: <1243489596.10450.24.camel@localhost> (from dev-zero@gentoo.org on Thu May 28 06:46:36 2009)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2009.05.28 06:46, Tiziano Müller 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.
>
[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
> reading
> only one cache file) vs. "reading all cache files".
>
> I did some performance measurements based on that. I have 1507
> installed
> packages with 5541 different versions/revisions.
>
> Reading from hot cache:
> 1507 files: ~50ms
> 5541 files: ~170ms
>
> 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
the dep tree is calculated. Lets say it takes an hour to do emerge
world, the time has increased from 3600 seconds to 3606 seconds or a
trivial 0.1666667%
We are clearly concentrating our efforts in wrong area, trying to
reduce the six seconds.
>
> 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
> 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?
>
> And I also don't understand your point of stating it's "bad design".
> 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
from Systems Design, before your write the Systems Requirement Document
and the System Implementation Plan and even the Top Level Design
document. ... thats a long time before you write any code.
I am against *all* and any metadata in the filename. Today, GLEP 55
proposes the add the EAIP, tomorrow, there will be something else,
the day after another thing ... and all because allowing EAPI set the
precedent.
You also make the error of assuming that with eapi-in-ebuild the
currently suggested approaches to extracting the EAPI from the ebuild
are the best and remain unchanged. Thats unlikely, as not a lot of work
has been done it yet.
>
>
> --
> Tiziano Müller
> 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
>
- --
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
=Ru66
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-05-28 17:56 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-26 18:57 [gentoo-dev] Gentoo Council Reminder for May 28 Tiziano Müller
2009-05-27 12:46 ` Ferris McCormick
2009-05-27 13:25 ` Ulrich Mueller
2009-05-27 19:55 ` Roy Bamford
2009-05-27 20:06 ` Ciaran McCreesh
2009-05-27 21:43 ` Roy Bamford
2009-05-27 21:52 ` Ciaran McCreesh
2009-05-27 23:26 ` [gentoo-dev] " Mark Bateman
2009-05-27 23:45 ` Ciaran McCreesh
2009-05-27 23:48 ` Jeroen Roovers
2009-05-27 23:54 ` Ciaran McCreesh
2009-05-28 3:58 ` Jeroen Roovers
2009-05-28 6:28 ` [gentoo-dev] How not to discuss Patrick Lauer
2009-05-28 18:14 ` Ciaran McCreesh
2009-05-28 18:36 ` Alec Warner
2009-05-28 18:58 ` Roy Bamford
2009-05-28 19:15 ` Joe Peterson
2009-05-28 19:40 ` Piotr Jaroszyński
2009-05-29 9:23 ` Marijn Schouten (hkBst)
2009-05-30 0:38 ` Alec Warner
2009-05-30 15:08 ` Joe Peterson
2009-05-28 18:49 ` Patrick Lauer
2009-05-28 19:11 ` Ciaran McCreesh
2009-05-29 2:41 ` [gentoo-dev] " Duncan
2009-05-29 2:12 ` Ryan Hill
2009-05-29 21:49 ` Patrick Lauer
2009-05-30 20:56 ` Ryan Hill
2009-05-31 1:57 ` Richard Freeman
2009-05-31 9:25 ` Thilo Bangert
2009-05-31 10:57 ` Duncan
2009-05-31 22:01 ` Richard Freeman
2009-06-02 8:20 ` Steven J Long
2009-06-02 12:53 ` Duncan
2009-06-04 14:11 ` Steven J Long
2009-06-02 15:38 ` Richard Freeman
2009-06-03 10:43 ` Marijn Schouten (hkBst)
2009-06-03 18:23 ` Richard Freeman
2009-05-28 5:46 ` [gentoo-dev] Gentoo Council Reminder for May 28 Tiziano Müller
2009-05-28 7:23 ` Patrick Lauer
2009-05-28 9:35 ` Tiziano Müller
2009-05-28 17:56 ` Roy Bamford [this message]
2009-05-28 18:04 ` Ciaran McCreesh
2009-05-28 18:30 ` Patrick Lauer
2009-05-28 18:48 ` Ciaran McCreesh
2009-05-28 19:19 ` Patrick Lauer
2009-05-28 19:26 ` Ciaran McCreesh
2009-05-28 19:42 ` Josh Saddler
2009-05-28 19:43 ` Ciaran McCreesh
2009-05-28 19:42 ` Roy Bamford
2009-05-28 19:54 ` Ciaran McCreesh
2009-05-28 21:31 ` Roy Bamford
2009-05-28 19:46 ` Patrick Lauer
2009-05-28 19:52 ` Ciaran McCreesh
2009-05-28 20:56 ` Patrick Lauer
2009-05-28 21:09 ` Ciaran McCreesh
2009-05-27 20:57 ` Joe Peterson
2009-05-27 21:58 ` Patrick Lauer
2009-05-27 22:12 ` Piotr Jaroszyński
2009-05-27 22:33 ` Patrick Lauer
2009-05-27 23:10 ` Piotr Jaroszyński
2009-05-28 6:36 ` Patrick Lauer
2009-06-01 20:42 ` Tiziano Müller
2009-05-28 13:11 ` Ferris McCormick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1243533366.3439.0@NeddySeagoon \
--to=neddyseagoon@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox