Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 09:33:44 +0100
> Alexis Ballier <aballier@g.o> 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