public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-dev] Issues regarding glep-55  (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
  @ 2009-02-24  7:08 99%                               ` Luca Barbato
  0 siblings, 0 replies; 1+ results
From: Luca Barbato @ 2009-02-24  7:08 UTC (permalink / raw
  To: gentoo-dev

Luca Barbato wrote:
> Ciaran McCreesh wrote:
>> Because your proposal addresses none of the underlying problems which
>> GLEP 55 was created to solve.

let's get some numbers to have an idea of the dimension of the problem.

domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list

domino portage # ls *-*/*/*.ebuild | wc -l
25761

domino portage # grep -l EAPI eclass/*.eclass | wc -l
22

domino portage # ls eclass/*.eclass | wc -l
240

there aren't eclasses setting EAPI directly.

eapi is set either using EAPI=X or EAPI="X"

domino portage # time grep EAPI *-*/*/*.ebuild > /dev/shm/eapi_files.list

real	0m1.019s
user	0m0.608s
sys	0m0.412s

domino portage # time (for a in *-*/*/*.ebuild*; do echo ${A##*.ebuild}; 
done) > /dev/null

real	0m0.916s
user	0m0.764s
sys	0m0.152s

domino portage # time emerge --regen > /dev/shm/regen

real	0m9.308s
user	0m7.648s
sys	0m1.664s


Restricting eapi so it could surely parsed using something as
complex as grep would and using a two stage parsing would increase to 
about 1/9

Using a dumb way to extract the eapi from extension seems to take 1/10

Is there any technical merit in putting eapi in the file extension while 
we could restrict the format the same way in file and have about the 
same, negligible, performance hit? (I used warm cache since you need the 
file anyway so you don't spend time to look it up twice or put it in 
cache twice)

Please come up with other numbers or saner implementations to compare.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
     [not found]     <1234257125.18160.2016.camel@localhost>
     [not found]     ` <1234450419.20950.2.camel@localhost>
     [not found]       ` <20090212160045.GB3642@comet>
     [not found]         ` <20090212161644.GD3642@comet>
     [not found]           ` <20090212162103.256b003f@snowcone>
     [not found]             ` <20090212171055.GA3652@comet>
     [not found]               ` <20090212172109.778fb268@snowcone>
     [not found]                 ` <20090212173743.GD3652@comet>
     [not found]                   ` <20090212180350.0d9a9df5@snowcone>
     [not found]                     ` <1235037961.13198.779.camel@localhost>
     [not found]                       ` <20090219125124.33eaa66c@snowcone>
     [not found]                         ` <1235077892.13198.1923.camel@localhost>
     [not found]                           ` <20090222171658.278ae167@halo.dirtyepic.sk.ca>
     [not found]                             ` <49A1E1CB.1000806@gentoo.org>
     [not found]                               ` <20090222234800.29d64b8d@snowcone>
2009-02-23  2:15                                 ` [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Luca Barbato
2009-02-24  7:08 99%                               ` Luca Barbato

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox