public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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-----




  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